Revert #133817
This reverts commit 0585134e70, reversing changes made to 5530869e0f.
#133817 unfortunately only converted the `println!` instances to `eprintln!`, meaning that some test output (via compiletest/bootstrap) was messed up because stdout/stderr output interleaved improperly when some `println!` instances were converted to `eprintln!` instances, while some `print!` instances remain unchanged. This made reading test output annoying for contributors cc #133879.
Closes#133879 by reverting.
#133817 can be relanded in the future when `print!` instances are also matched with `println!` instances.
cc `@clubby789`
This is a clean revert so I'm going to self-approve this PR.
Rename `core_pattern_type` and `core_pattern_types` lib feature gates to `pattern_type_macro`
That's what the gates are actually gating, and the single char difference in naming was not helpful either
fixes#128987
Update books
## rust-lang/book
12 commits in e16dd73690a6cc3ecdc5f5d94bbc3ce158a42e16..614c19cb4025636eb2ba68ebb3d44e3bd3a5e6e4
2024-12-02 16:22:15 UTC to 2024-11-26 21:15:51 UTC
- Fix more inverted uses of “shadowed” (rust-lang/book#4122)
- Fix a couple inverted uses of “shadowed” (rust-lang/book#4121)
- Fix confusion between variable `hello` and string `"hello"` (rust-lang/book#4118)
- Ch. 17: fix some wording issues (rust-lang/book#4117)
- Rephrase for clarity (rust-lang/book#3809)
- Link to tests section of rustc book for `cargo test -- --help` docs (rust-lang/book#4116)
- Drop a pedantry-triggering sentence about IEEE-754 (rust-lang/book#4114)
- Very small clarification on if let (rust-lang/book#4113)
- Ch17-05: Typos (rust-lang/book#4099)
- Ch20-01: Fix typos (rust-lang/book#4105)
- Add a short paragraph on editors and IDEs in installation (rust-lang/book#4112)
- Rust 2024: update Ch. 20 for new `unsafe` rules (rust-lang/book#4111)
## rust-lang/reference
8 commits in 5c86c739ec71b8bc839310ff47fa94e94635bba9..ede56d1bbe132bac476b5029cd6d7508ca9572e9
2024-11-25 17:23:35 +0000 to 2024-12-03 22:26:55 +0000
- Claim to follow Unicode 16 for lexing identifiers. (rust-lang/reference#1688)
- Clarify rules for on_unimplemented warnings (rust-lang/reference#1680)
- Enable triagebot merge-conflict notifications (rust-lang/reference#1682)
- Update default edition to 2024 for code examples (rust-lang/reference#1684)
- Fix weak keywords (rust-lang/reference#1685)
- `const` expression can borrow static items (rust-lang/reference#1610)
- Update function-pointer.md for stabilization of `extended_varargs_abi_support` (rust-lang/reference#1687)
- fix inconsistent spacing in example (rust-lang/reference#1686)
## edition-guide
1 commits in f48b0e842a3911c63240e955d042089e9e0894c7..128669297c8a7fdf771042eaec18b8adfaeaf0cd
2024-11-25 16:20:27 +0000 to 2024-12-03 22:02:43 +0000
- Fix `if_let_rescope` applicability (rust-lang/edition-guide#339)
## rust-lang/rustc-dev-guide
6 commits in 787b4166ccc67bd8f72a6e3ef6685ce9ce82909a..b21d99b770f9aceb0810c843847c52f86f45d2ed
2024-12-02 04:45:30 UTC to 2024-11-27 10:31:58 UTC
- Spell out `git submodule deinit -f --all` (rust-lang/rustc-dev-guide#2153)
- Explain how to deal with exploded git submodules (rust-lang/rustc-dev-guide#2152)
- Update `//@ proc-macro` aux build directive docs (rust-lang/rustc-dev-guide#2149)
- Remove `pretty-expanded` as it no longer exists (rust-lang/rustc-dev-guide#2147)
- Fix trivial typo (rust-lang/rustc-dev-guide#2148)
- Remove -Zfuel. (rust-lang/rustc-dev-guide#2032)
Add context to "const in pattern" errors
*Each commit addresses specific diagnostics.*
- Add primary span labels
- Point at `const` item, and `const` generic param definition
- Reword messages and notes
- Point at generic param through which an associated `const` is being referenced
- Silence const in pattern with evaluation errors when they come from `const` items that already emit a diagnostic
- On non-structural type in const used as pattern, point at the type that should derive `PartialEq`
Add lint against function pointer comparisons
This is kind of a follow-up to https://github.com/rust-lang/rust/pull/117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it.
-----
## `unpredictable_function_pointer_comparisons`
*warn-by-default*
The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.
### Example
```rust
fn foo() {}
let a = foo as fn();
let _ = a == foo;
```
### Explanation
Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.
----
This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`.
```@rustbot``` labels +I-lang-nominated
~~Edit: Blocked on https://github.com/rust-lang/libs-team/issues/323 being accepted and it's follow-up pr~~
This reverts commit 0585134e70, reversing
changes made to 5530869e0f.
The PR unfortunately only converted the `ln!` instances, meaning that
test output was messed up because stdout/stderr output interleaved when
some `println!` instances were converted to `eprintln!` instances, while
some `println!` instances remain unchanged.
Include LLDB and GDB visualizers in MSVC distribution
MSVC distributions currently don't include the lldb or GDB python files. MSVC and LLDB/GDB are not mutually exclusive (and end up being a common case with vscode + codelldb/lldb-dap), so they should probably be included.
the existing visualizers currently only partially work on MSVC due to the differences in how the debug info is generated, but they also only partially work on GNU anyway - both of which are actively being fixed.
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 +caa81728c37f5ccfa9a0979574b9272a67f8a286 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 +caa81728c37f5ccfa9a0979574b9272a67f8a286 check -q'
```
```console
Benchmark 1: CARGO_INCREMENTAL=0 cargo +caa81728c37f5ccfa9a0979574b9272a67f8a286 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 +caa81728c37f5ccfa9a0979574b9272a67f8a286 check -q'
```
```console
Benchmark 1: CARGO_INCREMENTAL=0 cargo +caa81728c37f5ccfa9a0979574b9272a67f8a286 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 +caa81728c37f5ccfa9a0979574b9272a67f8a286 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
León Orell Valerian Liehr