Use `eprintln` instead of `println` in bootstrap/compiletest/tidy
A big unconditional CTRL-F replace to start with to check if there's anything that CI expects to be on stdout
r? `@jieyouxu`
Improve code for FileName retrieval in rustdoc
Some calls were performed twice (first in `is_real_and_local` and then in the function calling it). Also the `FileName` was matched on a few times too.
r? `@notriddle`
rustdoc: Rename `set_back_info` to `restore_module_data`.
Follow-up to #133345, r? `@GuillaumeGomez`
Most of the references to `info` got removed as it was clear that `module_data` makes more sense here. Makes it clearer that `save_module_data` and `restore_module_data` are a pair.
compiletest: explain that UI tests are expected not to compile by default
```
error: ui test compiled successfully!
```
is not a very useful message for someone new to the test suite, so change the wording and add a note to explain
Update wasm-component-ld to 0.5.11
This pulls in an update that supports ``@`-files` used to pass arguments to linkers to fix invocations on Windows that are large.
Closes#133649
improve TagEncoding::Niche docs, sanity check, and UB checks
Turns out the `niche_variants` range can actually contain the `untagged_variant`. We should report this as UB in Miri, so this PR implements that.
Also rename `partially_check_layout` to `layout_sanity_check` for better consistency with how similar functions are called in other parts of the compiler.
Turns out my adjustments to the transmutation logic also fix https://github.com/rust-lang/rust/issues/126267.
Gate async fn trait bound modifier on `async_trait_bounds`
This PR moves `async Fn()` trait bounds into a new feature gate: `feature(async_trait_bounds)`. The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier, so we need to gate that separately.
We're trying to work on the general vision of `async` trait bound modifier general in: https://github.com/rust-lang/rfcs/pull/3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
switch `jemalloc-sys` back to `tikv-jemalloc-sys`, and update to 0.6.0
Some context:
- we used to use jemalloc bindings from https://github.com/gnzlbg/jemallocator, since #55238
- that crate was abandoned, picked up as a fork in https://github.com/tikv/jemallocator, so we switched to that in #83152.
- then they were able to publish to the original `jemalloc-sys` bindings crate, and `jemalloc-sys` and `tikv-jemalloc-sys` became the same thing -- so I switched back to the OG crate in #96790
- they're now having publishing problems again: I've been waiting for https://github.com/tikv/jemallocator/pull/96 for the `jemalloc-sys` 0.6.0 update for a few months, but `tikv-jemalloc-sys` is already updated to 0.6.0.
A perf run showed some improvements, so this PR switches back to `tikv-jemalloc-sys` to update to 0.6.0.
Unify `sysroot_target_{bin,lib}dir` handling
Follow-up to https://github.com/rust-lang/rust/pull/131405#discussion_r1826558962 where `sysroot_target_bindir` had to do some dancing because the sysroot ensure logic embedded in `sysroot_target_libdir` returned `$sysroot/$relative_lib/rustlib/$target/lib` and not the `rustlib` parent `$sysroot/$relative_lib/rustlib/`.
This PR pulls out the sysroot ensure logic into a helper, and return `$sysroot/$relative_lib/rustlib/` instead so `sysroot_target_bindir` doesn't have to do parent traversal from the path returned from `sysroot_target_libdir`, and also make them easier to follow in that they are now clearly closely related based on the common target sysroot ensure logic.
Change `AttrArgs::Eq` to a struct variant
Cleanups for simplifying https://github.com/rust-lang/rust/pull/131808
Basically changes `AttrArgs::Eq` to a struct variant and then avoids several matches on `AttrArgsEq` in favor of methods on it. This will make future refactorings simpler, as they can either keep methods or switch to field accesses without having to restructure code
Reducing `target_feature` check-cfg merge conflicts
It was rightfully pointed in https://github.com/rust-lang/rust/pull/133099#discussion_r1862490542 that the expected values for the `target_feature` cfg are regularly updated and unfortunately the check-cfg tests for it are very merge-conflict prone.
This PR aims at drastically reducing the likely-hood of those, by normalizing the "and X more" diagnostic, as well as making the full expected list multi-line instead of being on a single one.
cc `@RalfJung`
r? `@jieyouxu`
add "profiler" and "optimized-compiler-builtins" option coverage for ci-rustc
Adds "profiler" and "optimized-compiler-builtins" option coverage in CI-rustc config compatibility check.
Resolves#133675
Use c"lit" for CStrings without unwrap
I've reviewed uses of `CString::new("lit")`.
Some could be changed to `c"lit"`. Some could be changed to `c"lit".to_owned()`, avoiding an `unwrap()`.
Many `CString` documentation examples could be simplified. I deliberately haven't changed all the examples to use the exact same expression, so that they can demonstrate many ways of creating `CString`s.
I've left UI tests mostly unchanged, because `c""` requires edition 2021, but most UI tests use 2015, and I didn't want to accidentally change what the tests are testing.
build `rustc` with 1 CGU on `aarch64-apple-darwin`
Distribute `aarch64-apple-darwin` artifacts built with `rust.codegen-units=1`, like we already do on Linux/Windows/macOS Intel.
1. Performance results (only wall-time on mac as usual)
- I only did some `ripgrep` check builds (the revision from rustc-perf), because we had noticeable wins in wall-time there back then on linux. It's a ~2-4% (mostly 3%) improvement on local builds.
```console
Benchmark 1: cargo +caa81728c3 check -q
Time (mean ± σ): 5.800 s ± 0.087 s [User: 16.048 s, System: 2.294 s]
Range (min … max): 5.725 s … 6.028 s 10 runs
Benchmark 2: cargo +41f40c97bbff6c8642f5510d0be283551b095b70 check -q
Time (mean ± σ): 5.551 s ± 0.037 s [User: 15.451 s, System: 2.252 s]
Range (min … max): 5.477 s … 5.602 s 10 runs
Summary
'cargo +41f40c97bbff6c8642f5510d0be283551b095b70 check -q' ran
1.04 ± 0.02 times faster than 'cargo +caa81728c3 check -q'
```
```console
Benchmark 1: CARGO_INCREMENTAL=0 cargo +caa81728c3 check -q
Time (mean ± σ): 5.743 s ± 0.030 s [User: 16.005 s, System: 2.249 s]
Range (min … max): 5.720 s … 5.792 s 5 runs
Benchmark 2: CARGO_INCREMENTAL=0 cargo +41f40c97bbff6c8642f5510d0be283551b095b70 check -q
Time (mean ± σ): 5.469 s ± 0.055 s [User: 15.244 s, System: 2.110 s]
Range (min … max): 5.404 s … 5.524 s 5 runs
Summary
'CARGO_INCREMENTAL=0 cargo +41f40c97bbff6c8642f5510d0be283551b095b70 check -q' ran
1.05 ± 0.01 times faster than 'CARGO_INCREMENTAL=0 cargo +caa81728c3 check -q'
```
```console
Benchmark 1: CARGO_INCREMENTAL=0 cargo +caa81728c3 check -q -j1
Time (mean ± σ): 15.092 s ± 0.049 s [User: 11.969 s, System: 1.665 s]
Range (min … max): 15.052 s … 15.165 s 5 runs
Benchmark 2: CARGO_INCREMENTAL=0 cargo +41f40c97bbff6c8642f5510d0be283551b095b70 check -q -j1
Time (mean ± σ): 14.623 s ± 0.035 s [User: 11.520 s, System: 1.619 s]
Range (min … max): 14.593 s … 14.682 s 5 runs
Summary
'CARGO_INCREMENTAL=0 cargo +41f40c97bbff6c8642f5510d0be283551b095b70 check -q -j1' ran
1.03 ± 0.00 times faster than 'CARGO_INCREMENTAL=0 cargo +caa81728c3 check -q -j1'
```
2. Effects on code size on `aarch64-apple-darwin`: it's a 13.24% reduction on `librustc_driver.dylib`
- [before](https://ci-artifacts.rust-lang.org/rustc-builds/caa81728c37f5ccfa9a0979574b9272a67f8a286/rustc-nightly-aarch64-apple-darwin.tar.xz): 173452888 (57.3 MB compressed).
- [after](https://ci-artifacts.rust-lang.org/rustc-builds/41f40c97bbff6c8642f5510d0be283551b095b70/rustc-nightly-aarch64-apple-darwin.tar.xz): 150471368 (55.2 MB compressed, -3.7% here).
3. Effects on CI
- the [1st try build](https://github.com/rust-lang-ci/rust/actions/runs/12118946198/job/33784512526) took 1h31
- the [2nd try build](https://github.com/rust-lang-ci/rust/actions/runs/12121452825/job/33792429553) took 1h28
- I don't know how long the builder usually takes
remove `Ty::is_copy_modulo_regions`
Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.
I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.
r? `@compiler-errors` cc #132279
Add `needs-target-has-atomic` directive
Before this PR, the test writer has to specify platforms and architectures by hand for targets that have differing atomic width support. `#[cfg(target_has_atomic="...")]` is not quite the same because (1) you may have to specify additional matchers manually which has to be maintained individually, and (2) the `#[cfg]` blocks does not communicate to compiletest that a test would be ignored for a given target.
This PR implements a `//@ needs-target-has-atomic` directive which admits a comma-separated list of required atomic widths that the target must satisfy in order for the test to run.
```
//@ needs-target-has-atomic: 8, 16, ptr
```
See <https://github.com/rust-lang/rust/issues/87377>.
This PR supersedes #133095 and is co-authored by `@kei519,` because it was somewhat subtle, and it turned out easier to implement than to review.
rustc-dev-guide docs PR: https://github.com/rust-lang/rustc-dev-guide/pull/2154
Remove `//@ compare-output-lines-by-subset`
There was only ever one test which used this flag, and it was removed in https://github.com/rust-lang/rust/pull/132244. I think this is a bad flag that should never have been added; comparing by subset makes the test failures extremely hard to debug. Any test that needs complicated output filtering like this should just use run-make instead.
Note that this does not remove the underlying comparison code, because it's still used if `runner` is set. I don't quite understand what's going on there, but since we still test on other platforms and in CI that the full output is accurate, I think it will be easier to debug than a test that uses compare-by-subset unconditionally.
rustc-dev-guide update PR: https://github.com/rust-lang/rustc-dev-guide/pull/2151
rustdoc-json: Include safety of `static`s
`static`s in an `extern` block can have an associated safety annotation ["because there is nothing guaranteeing that the bit pattern at the static’s memory is valid for the type it is declared with"](https://doc.rust-lang.org/reference/items/external-blocks.html#statics). Rustdoc already knows this and displays in for HTML. This PR also includes it in JSON.
Inspired by https://github.com/obi1kenobi/cargo-semver-checks/issues/975 which needs this, but it's probably useful in other places.
r? `@GuillaumeGomez.` Possibly easier to review commit-by-commit.
Eliminate magic numbers from expression precedence
Context: see https://github.com/rust-lang/rust/pull/133140.
This PR continues on backporting Syn's expression precedence design into rustc. Rustc's design used mysterious integer quantities represented variously as `i8` or `usize` (e.g. `PREC_CLOSURE = -40i8`), a special significance around `0` that is never named, and an extra `PREC_FORCE_PAREN` precedence level that does not correspond to any expression. Syn's design uses a C-like enum with variants that clearly correspond to specific sets of expression kinds.
This PR is a refactoring that has no intended behavior change on its own, but it unblocks other precedence work that rustc's precedence design was poorly suited to accommodate.
- Asymmetrical precedence, so that a pretty-printer can tell `(return 1) + 1` needs parens but `1 + return 1` does not.
- Squashing the `Closure` and `Jump` cases into a single precedence level.
- Numerous remaining false positives and false negatives in rustc pretty-printer's parenthesization of macro metavariables, for example in `$e < rhs` where $e is `lhs as Thing<T>`.
FYI `@fmease` — you don't need to review if rustbot picks someone else, but you mentioned being interested in the followup PRs.
