use `Self` alias in self types rather than manually substituting it
Of the rougly 145 uses of `self: Ty` in the standard library, 5 of them don't use `Self` but instead choose to manually "substitute" the `impl`'s self type into the type.
This leads to weird behavior sometimes (https://github.com/rust-lang/rust/issues/140611#issuecomment-2883761300) -- **to be clear**, none of these usages actually trigger any bugs, but it's possible that they may break in the future (or at least lead to lints), so let's just "fix" them proactively.
Get rid of unnecessary `BufDisplay` abstraction
r? `@GuillaumeGomez` , since you reviewed the introduction of `BufDisplay` in #136784 . Not sure when it became unnecessary, but it did :)
(feel free to reassign if you wish)
`core_float_math`: Move functions to `math` module
When these functions were added in https://github.com/rust-lang/rust/pull/138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over the `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute.
We ran into this in [Color](https://github.com/linebender/color) and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this "breakage" doesn't adversely impact anyone else.
I believe that I've made the module unstable correctly. I presume that this does not require a test to make sure stable code can't depend on the module existing?
I've left the stability attribute on each function - happy to tweak this if a different pattern is more correct.
Tracking issue for `core_float_math`: https://github.com/rust-lang/rust/issues/137578.
This PR is as requested in https://github.com/rust-lang/rust/pull/138087.
r? `@tgross35`
Recommended reviewing with whitespace hidden.
(This is my first PR to `std/core`/this repository, as far as I can remember)
Add TRACING_ENABLED to Machine and add enter_trace_span!()
This PR adds the necessary infrastructure to make it possible to do tracing calls from within `rustc_const_eval` when running Miri, while making sure they don't impact the performance of normal compiler execution. This is done by adding a `const` boolean to `Machine`, false by default, but that will be set to true in Miri only. The tracing macro `enter_trace_span!()` checks if it is true before doing anything, and since the value of a `const` is known at compile time, if it it false it the whole tracing call should be optimized out.
I will soon open further PRs to add tracing macro calls similar to this one, so that afterwards it will be possible to learn more about Miri's time spent in the various interpretation steps:
```rs
let _guard = enter_trace_span!(M, "eval_statement", "{:?}", stmt);
```
r? `@RalfJung`
When these functions were added in
https://github.com/rust-lang/rust/pull/138087
It made a relatively common pattern for emulating
these functions using an extension trait (which
internally uses `libm`) much more fragile.
If `core::f32` happened to be imported by the user
(to access a constant, say), then that import in
the module namespace would take precedence over
`f32` in the type namespace for resolving these
functions, running headfirst into the stability
attribute.
We ran into this in Color -
https://github.com/linebender/color - and chose to
release the remedial 0.3.1 and 0.2.4, to allow
downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them
into a new module should not have any long-term
concerns, and ensures that this breakage doesn't
adversely impact anyone else.
update llvm-tools logic for `dist` and `install` steps
First commit aligns `build_steps::compile` and `build_steps::dist` logics for copying llvm-tools, and the second commit adds the correct `should_run` condition for `LlvmTools` step as the previous one was clearly incorrect.
Fixes#140913
make std::intrinsics functions actually be intrinsics
Most of the functions in `std::intrinsics` are actually intrinsics, but some are not: for historical reasons, `std::intrinsics::{copy,copy_nonoverlapping,write_bytes}` are accessible on stable, and the versions in `std::ptr` are just re-exports. These functions are not intrinsics, but wrappers around the intrinsic, because they add extra debug assertions.
This PR makes the functions in `std::intrinsics` actually be intrinsics.
- The advantage is that we can now use it in tests that need to directly call the intrinsic, thus removing a footgun for compiler development. We also remove the extended user-facing doc comments of these functions out of a file that should be largely internal documentation.
- The downside is that if users are using those functions directly, they will not get the debug assertions any more. Note however that those users are already ignoring a deprecation warning, so I think this is fine. Furthermore, if someone imports the `intrinsic` name of this function and turns that into a function pointer, that will no longer work, since only the wrapper functions can be turned into a function pointer. I would be rather surprised if anyone did this, though... and again, they must have already ignored a deprecation warning. Still, seems worth a crater run, if there's general agreement that we want to go ahead with this change.
(`intrinsics::drop_in_place` also remains not-an-intrinsic, which bugs me, but oh well, not much we can do about it; we can't remove it from the module as the path is accidentally-stable.)
Cc `@rust-lang/libs-api` `@saethlin`
Properly remove Noratrieb from review rotation
I've put myself on vacation a while ago, but really I just want to remove myself from the queue because I couldn't get around to reviewing all the PRs, I'm still here and available :3.
Update books
## rust-lang/book
4 commits in d33916341d480caede1d0ae57cbeae23aab23e88..230c68bc1e08f5f3228384a28cc228c81dfbd10d
2025-05-19 14:25:14 UTC to 2025-05-08 21:28:56 UTC
- Chapter 6 from tech review (rust-lang/book#4370)
- Chapter 5 from tech review (rust-lang/book#4359)
- Chapter 4 from tech review (rust-lang/book#4358)
- Chapter 3 from tech review (rust-lang/book#4353)
## rust-lang/reference
12 commits in 387392674d74656f7cb437c05a96f0c52ea8e601..acd0231ebc74849f6a8907b5e646ce86721aad76
2025-05-19 15:41:22 UTC to 2025-05-06 21:36:01 UTC
- Add doc for avx512 target features (rust-lang/reference#1778)
- Parse grammar without regexes (rust-lang/reference#1827)
- Parse optionals and repeats without regexes (rust-lang/reference#1826)
- Fix grammar for `RangePatternBound` regarding literals (rust-lang/reference#1825)
- Fix grammar for `LiteralPattern` regarding `-` (rust-lang/reference#1824)
- Doc: Add the LoongArch stabilized target features (rust-lang/reference#1707)
- Fix naked em-dash (rust-lang/reference#1820)
- Add missing attribute for statement macros (rust-lang/reference#1819)
- Make linked rules are clicked, highlight the color (rust-lang/reference#1817)
- Use the reference grammar for inline assembly (rust-lang/reference#1807)
- Fix typo in introduction (rust-lang/reference#1810)
- Add an example admonition (rust-lang/reference#1812)
## rust-lang/rust-by-example
2 commits in 8a8918c698534547fa8a1a693cb3e7277f0bfb2f..c9d151f9147c4808c77f0375ba3fa5d54443cb9e
2025-05-13 17:49:05 UTC to 2025-05-13 17:48:43 UTC
- fix(docs): standardize on `no_run` attribute for documentation examples (rust-lang/rust-by-example#1929)
- Fix typo in Japanese translation (rust-lang/rust-by-example#1928)
trim cache module in utils bootstrap
We don't use other variants of Interner in bootstrap, so this PR streamlines the bootstrap cache utils module.
r? `@onur-ozkan`
Replace `try_reserve_exact` with `try_with_capacity` in `std::fs::read`
This change restores the previous behavior prior to #117925. That PR was made to handle OOM errors that turn into a panic with `Vec::with_capacity`. `try_reserve_exact` was used for that since there was no `try_with_capacity` method at the time. It was added later in #120504. I think it'd a better fit here.
I've put myself on vacation a while ago, but really I just want to remove myself from the queue because I couldn't get around to reviewing all the PRs, I'm still here and available :3.
Rollup of 6 pull requests
Successful merges:
- #131200 (Handle `rustc_query_system` cases of `rustc::potential_query_instability` lint)
- #141244 (windows: document that we rely on an undocumented property of GetUserProfileDirectoryW)
- #141247 (skip compiler tools sanity checks on certain commands)
- #141248 (fix data race in ReentrantLock fallback for targets without 64bit atomics)
- #141249 (introduce common macro for `MutVisitor` and `Visitor` to dedup code)
- #141253 (Warning added when dependency crate has async drop types, and the feature is disabled)
r? `@ghost`
`@rustbot` modify labels: rollup
Warning added when dependency crate has async drop types, and the feature is disabled
In continue of https://github.com/rust-lang/rust/pull/141031.
When dependency crate has non-empty `adt_async_destructor` table in metadata, and `async_drop` feature is disabled for local crate, warning will be emitted.
Test `dependency-dropped` has two revisions - with and without feature enabled. With feature enabled, async drop for dropee is executed ("Async drop" printed). Without the feature enabled, sync drop is executed ("Sync drop" printed) and warning is emitted.
Warning example:
```
warning: found async drop types in dependecy `async_drop_dep`, but async_drop feature is disabled for `dependency_dropped`
--> $DIR/dependency-dropped.rs:7:1
|
LL | #![cfg_attr(with_feature, feature(async_drop))]
| ^
|
= help: if async drop type will be dropped in a crate without `feature(async_drop)`, sync Drop will be used
```
introduce common macro for `MutVisitor` and `Visitor` to dedup code
helps with #127615.
I can do everything in one go but I figured it might be worth it to open a PR first for vibeck.
r? oli-obk
fix data race in ReentrantLock fallback for targets without 64bit atomics
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/269128-miri/topic/reentrant.20lock.20failure.20on.20musl) for details: the address used to identify a thread might get lazily allocated inside `tls_addr()`, so if we call that *after* doing the `tls_addr.load()` it is too late to establish synchronization with prior threads that used the same address -- the `load()` thus races with the `store()` by that prior thread, and might hence see outdated values, and then the entire logic breaks down.
r? `@joboet`
Rollup of 5 pull requests
Successful merges:
- #140847 (coverage: Detect unused local file IDs to avoid an LLVM assertion)
- #141117 (opt-dist: fix deprecated BOLT -icf=1 option)
- #141225 (more ice tests)
- #141239 (dladdr cannot leave dli_fname to be null)
- #141242 (in `tests/ui/asm/aarch64/parse-error.rs`, only test cases specific to that target)
r? `@ghost`
`@rustbot` modify labels: rollup
in `tests/ui/asm/aarch64/parse-error.rs`, only test cases specific to that target
this is more in line with the x86 parse error tests at https://github.com/rust-lang/rust/blob/master/tests/ui/asm/x86_64/x86_64_parse_error.rs. We could at this point use minicore so that these tests run no matter the host target?
`tests/ui/asm/aarch64/parse-error.rs` was mostly a copy of https://github.com/rust-lang/rust/blob/master/tests/ui/asm/parse-error.rs, though a bit out of date. The only aarch64-specific tests are those that talk about register names. Here is a diff between those two files:
```diff
--- <unnamed>
+++ <unnamed>
`@@` -1,4 +1,4 `@@`
-//@ needs-asm-support
+//@ only-aarch64
use std::arch::{asm, global_asm};
`@@` -36,36 +36,12 `@@`
//~^ ERROR expected one of
asm!("{}", options(), const foo);
//~^ ERROR attempt to use a non-constant value in a constant
-
- // test that asm!'s clobber_abi doesn't accept non-string literals
- // see also https://github.com/rust-lang/rust/issues/112635
- asm!("", clobber_abi());
- //~^ ERROR at least one abi must be provided
asm!("", clobber_abi(foo));
//~^ ERROR expected string literal
asm!("", clobber_abi("C" foo));
//~^ ERROR expected one of `)` or `,`, found `foo`
asm!("", clobber_abi("C", foo));
//~^ ERROR expected string literal
- asm!("", clobber_abi(1));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(()));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(uwu));
- //~^ ERROR expected string literal
- asm!("", clobber_abi({}));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(loop {}));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(if));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(do));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(<));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(.));
- //~^ ERROR expected string literal
-
asm!("{}", clobber_abi("C"), const foo);
//~^ ERROR attempt to use a non-constant value in a constant
asm!("", options(), clobber_abi("C"));
`@@` -76,7 +52,15 `@@`
//~^^ ERROR argument never used
//~^^^ ERROR attempt to use a non-constant value in a constant
//~^^^^ ERROR attempt to use a non-constant value in a constant
-
+ asm!("", a = in("x0") foo);
+ //~^ ERROR explicit register arguments cannot have names
+ asm!("{a}", in("x0") foo, a = const bar);
+ //~^ ERROR attempt to use a non-constant value in a constant
+ asm!("{a}", in("x0") foo, a = const bar);
+ //~^ ERROR attempt to use a non-constant value in a constant
+ asm!("{1}", in("x0") foo, const bar);
+ //~^ ERROR positional arguments cannot follow named arguments or explicit register arguments
+ //~^^ ERROR attempt to use a non-constant value in a constant
asm!("", options(), "");
//~^ ERROR expected one of
asm!("{}", in(reg) foo, "{}", out(reg) foo);
`@@` -109,13 +93,11 `@@`
global_asm!("{}", const(reg) FOO);
//~^ ERROR expected one of
global_asm!("", options(FOO));
-//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO`
-global_asm!("", options(FOO,));
-//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO`
+//~^ ERROR expected one of
global_asm!("", options(nomem FOO));
-//~^ ERROR expected one of `)` or `,`, found `FOO`
+//~^ ERROR expected one of
global_asm!("", options(nomem, FOO));
-//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO`
+//~^ ERROR expected one of
global_asm!("{}", options(), const FOO);
global_asm!("", clobber_abi(FOO));
//~^ ERROR expected string literal
`@@` -129,8 +111,6 `@@`
//~^ ERROR `clobber_abi` cannot be used with `global_asm!`
global_asm!("{}", options(), clobber_abi("C"), const FOO);
//~^ ERROR `clobber_abi` cannot be used with `global_asm!`
-global_asm!("", clobber_abi("C"), clobber_abi("C"));
-//~^ ERROR `clobber_abi` cannot be used with `global_asm!`
global_asm!("{a}", a = const FOO, a = const BAR);
//~^ ERROR duplicate argument named `a`
//~^^ ERROR argument never used
`@@` -142,16 +122,3 `@@`
//~^ ERROR asm template must be a string literal
global_asm!("{1}", format!("{{{}}}", 0), const FOO, const BAR);
//~^ ERROR asm template must be a string literal
-
-global_asm!("{}", in(reg));
-//~^ ERROR the `in` operand cannot be used with `global_asm!`
-global_asm!("{}", out(reg));
-//~^ ERROR the `out` operand cannot be used with `global_asm!`
-global_asm!("{}", lateout(reg));
-//~^ ERROR the `lateout` operand cannot be used with `global_asm!`
-global_asm!("{}", inout(reg));
-//~^ ERROR the `inout` operand cannot be used with `global_asm!`
-global_asm!("{}", inlateout(reg));
-//~^ ERROR the `inlateout` operand cannot be used with `global_asm!`
-global_asm!("{}", label(reg));
-//~^ ERROR the `label` operand cannot be used with `global_asm!`
```
dladdr cannot leave dli_fname to be null
There are two places in the repo calling `dladdr`, and they are inconsistent wrt their assumption of whether the `dli_fname` field can be null. Let's make them consistent. I see nothing in the docs that allows it to be null, but just to be on the safe side let's make this an assertion so hopefully we get a report if that ever happens.
coverage: Detect unused local file IDs to avoid an LLVM assertion
Each function's coverage metadata contains a *local file table* that maps local file IDs (used by the function's mapping regions) to global file IDs (shared by all functions in the same CGU).
LLVM requires all local file IDs to have at least one mapping region, and has an assertion that will fail if it detects a local file ID with no regions. To make sure that assertion doesn't fire, we need to detect and skip functions whose metadata would trigger it.
(This can't actually happen yet, because currently all of a function's spans must belong to the same file and expansion. But this will be an important edge case when adding expansion region support.)
