compiletest: Clarify that `--no-capture` is needed with `--verbose`
Confusingly, this does not make compile test print what command is used to run a ui test:
./x test tests/ui/panics/abort-on-panic.rs --verbose
It is also necessary to pass `--no-capture`, like this:
./x test tests/ui/panics/abort-on-panic.rs --verbose --no-capture
Then you will see prints like this:
executing cd "/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next" && \
RUSTC="/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" \
RUST_TEST_THREADS="32" \
"/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next/a"
Add a hint in the code for this that would have helped me figure this out.
(See https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/compiltest.20show.20rustc.20commands.3F for some more context.)
Remove "intermittent" wording from `ReadDir`
`ReadDir` claims that `next` will return an error "if there’s some sort of intermittent IO error during iteration". I'm really not sure what this was intended to mean but the implementations will simply return all OS errors encountered during iteration to the user. What else can they do?
This is technically a change in the documented API but seeing as how it doesn't bear any relationship with the implementation I don't think it needs a libs-api fcp.
Delay replacing escaping bound vars in `FindParamInClause`
By uplifting the `BoundVarReplacer`, which is used by (e.g.) normalization to replace escaping bound vars that are encountered when folding binders, we can use a similar strategy to delay the instantiation of a binder's contents in the `FindParamInClause` used by the new trait solver.
This should alleviate the recently added requirement that `Binder<T>: TypeVisitable` only if `T: TypeFoldable`, which was previously required b/c we were calling `enter_forall` so that we could structurally normalize aliases that we found within the predicates of a param-env clause.
r? lcnr
doc: mention that intrinsics should not be called in user code
Intrinsic functions declared in `std::intrinsics` are an implementation detail and should not be called directly by the user. The compiler explicitly warns against their use in user code:
```
warning: the feature `core_intrinsics` is internal to the compiler or standard library
--> src/lib.rs:1:12
|
1 | #![feature(core_intrinsics)]
| ^^^^^^^^^^^^^^^
|
= note: using it is strongly discouraged
= note: `#[warn(internal_features)]` on by default
```
[**Playground link**]
This PR documents what the compiler warning says: these intrinsics should not be used in user code.
[**Playground link**]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1c893b0698291f550bbdde0151fd221b
Pre-install JS dependencies in tidy Dockerfile
Also fixes passing `TIDY_PRINT_DIFF` to tidy, which has been passed to `npm install` rather than to tidy after the latest change here.
r? `@GuillaumeGomez`
Fixes: https://github.com/rust-lang/rust/issues/142433
Don't hardcode the intrinsic return types twice in the compiler
We already manually check intrinsic types in intrinsicck so we don't need to do it in the interpreter
Rework how the disallowed qualifier in function type diagnostics are generated
This pull request fixes two independent issues:
1. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), the diagnostic suggests removing the incorrect qualifier. Fixes https://github.com/rust-lang/rust/issues/142268, which is an issue created by https://github.com/rust-lang/rust/pull/133151. This is fixed by moving the check into `parse_fn_front_matter`, where better span information is available to generate the right suggestions.
2. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), `cargo fix` crashes because "cannot replace slice of data that was already replaced". This is fixed by not generating a suggestion for the "wrong order" diagnostic if the "disallowed qualifier" diagnostic is triggered.
There is a commit with failing tests so the test diff is clearer
r? `@jdonszelmann`
tests: Minicore `extern "gpu-kernel"` feature test
Explicitly cross-build it for GPU targets and check it errors on hosts. A relatively minor cleanup from my other ABI-related PRs that I got tired of rebasing.
builtin dyn impl no guide inference
cc https://github.com/rust-lang/rust/pull/141347
we can already slightly restrict this behavior in the old solver, so why not do so. Needs crater and an FCP.
r? `@compiler-errors`
Allow initializing logger with additional tracing Layer
This PR adds functions to the `rustc_log` and `rustc_driver_impl` crates to allow initializing the logger with an additional `tracing_subscriber::Layer`. This will be used in Miri to save trace events to file using e.g. [`tracing-chrome`](https://github.com/thoren-d/tracing-chrome)'s or [`tracing-tracy`](https://github.com/nagisa/rust_tracy_client)'s `Layer`s.
Additional context on the choice of signature can be found in [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Adding.20a.20dependency.20to.20Miri.20that.20depends.20on.20a.20rustc.20dep/near/515707776).
I re-exported `tracing_subscriber::{Layer, Registry};` from `rustc_log` so that `rustc_driver_impl` can use them in the function signature without depending on `tracing_subscriber` directly. I did this to avoid copy-pasting the dependency line with all of the enabled features from the `rustc_log` to the `rustc_driver_impl`'s Cargo.toml, which would have possibly led to redundancies and inconsistencies.
r? `@RalfJung`
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-2.rs:22:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-2.rs:16:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-2.rs:5:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
LL + #[derive(Serialize, Deserialize)]
LL | enum B {
|
```
Partially address #47608. This PR doesn't find [macros that haven't yet been imported by name](https://github.com/rust-lang/rust/pull/109278/commits/af945cb86e03b44a4b6dc4d54ec1424b00a2349e).
Confusingly, this does not make compile test print what command is used
to run a ui test:
./x test tests/ui/panics/abort-on-panic.rs --verbose
It is also necessary to pass `--no-capture`, like this:
./x test tests/ui/panics/abort-on-panic.rs --verbose --no-capture
Now you will see prints like this:
executing cd "/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next" && \
RUSTC="/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" \
RUST_TEST_THREADS="32" \
"/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next/a"
Add a hint in the code for this that would have helped me figure this out.
Intrinsic functions declared in `std::intrinsics` are an implementation
detail and should not be called directly by the user. The compiler
explicitly warns against their use in user code:
```
warning: the feature `core_intrinsics` is internal to the compiler or standard library
--> src/lib.rs:1:12
|
1 | #![feature(core_intrinsics)]
| ^^^^^^^^^^^^^^^
|
= note: using it is strongly discouraged
= note: `#[warn(internal_features)]` on by default
```
[**Playground link**]
This PR documents what the compiler warning says: these intrinsics should
not be called outside the standard library.
[**Playground link**]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1c893b0698291f550bbdde0151fd221b
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from
`libc`.
I don't really trust callgrind when it says I've turn 81 billion
instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20
times
without incr" method and it went from 0.31s-0.45s to 0.25s
constistently.
(Profiled, and "benchmarked") on tokio.
What I can get behind is via `strlen_on_c_strings` changing from 31
million instructions into 76k. 🎉🥳
changelog: [`strlen_on_c_strings`]: Optimize it by 99.75%
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#138016 (Added `Clone` implementation for `ChunkBy`)
- rust-lang/rust#141162 (refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking)
- rust-lang/rust#141474 (Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints)
- rust-lang/rust#141947 (Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field.)
- rust-lang/rust#142252 (Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations)
- rust-lang/rust#142337 (miri: add flag to suppress float non-determinism)
r? `@ghost`
`@rustbot` modify labels: rollup
Upgrade `object`, `addr2line`, and `unwinding` in the standard library
Object:
0.37.0 is a semver-breaking release but the only breakage is in `elf::R_RISCV_GNU_*` and `pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld. This API is not used by `std`, so we should be fine to upgrade.
This new version also includes functionality for parsing Wasm object files that we may eventually like to make use of.
Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370
Addr2line:
0.25.0 is a breaking change only because it upgrades the `gimli` version. It also includes a change to the `compiler-builtins` dependency that helps with [1].
Changelog: https://github.com/gimli-rs/addr2line/blob/master/CHANGELOG.md#0250-20250611
[1]: https://github.com/rust-lang/rust/issues/142265
Update dependencies in `library/Cargo.lock`
This removes the `compiler_builtins` dependency from a handful of library dependencies, which is progress toward [1].
[1]: https://github.com/rust-lang/rust/issues/142265
assert more in release in `rustc_ast_lowering`
My understanding of the compiler's architecture is that in the `ast_lowering` crate, we are constructing the HIR as a one-time thing per crate. This is after tokenizing, parsing, resolution, expansion, possible reparsing, reresolution, reexpansion, and so on. In other words, there are many reasons that perf-focused PRs spend a lot of time touching `rustc_parse`, `rustc_expand`, `rustc_ast`, and then `rustc_hir` and "onwards", but `ast_lowering` is a little bit of an odd duck.
In this crate, we have a number of debug assertions. Some are clearly expensive checks that seem like they are prohibitive to run in actual optimized compiler builds, but then there are a number that are simple asserts on integer equalities, `is_empty`, or the like. I believe we should do some of them even in release builds, because the correctness gain is worth the performance cost: almost zero.
tests: Split dont-shuffle-bswaps along opt-levels and arches
This duplicates dont-shuffle-bswaps in order to make each opt level its own test. Then -opt3.rs gets split into a revision per arch we want to test, with certain architectures gaining new target-cpu minimums.
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
