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
intrinsics: rename min_align_of to align_of
Now that `pref_align_of` is gone (https://github.com/rust-lang/rust/pull/141803), we can give the intrinsic backing `align_of` its proper name.
r? `@workingjubilee` or `@bjorn3`
Add bootstrap option to compile a tool with features
Add an option to specify which features to build a tool with, e.g. it will be useful to build Miri with tracing enabled:
```toml
tool-config.miri.features = ["tracing"]
```
See [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Passing.20--features.20to.20Miri.20build.20using.20.2E.2Fx.2Epy/with/523564773) for the options considered. If the final decision will be different than what I wrote now, I will update the code as needed. The reason why the option is `tool-config.miri.features` instead of something like `tool-features.miri` is to possibly allow adding more tool-specific configurations in the future.
I didn't do any validation of the keys of the `tool-config` hashmap, since I saw that no validation is done on the `tools` hashset either.
I don't like much the fact that features can be chosen by various places of the codebase: `Step`s can have some fixed `extra_features`, `prepare_tool_cargo` will add features depending on some bootstrapping options, and the newly added option can also contribute features to tools. However I think it is out of scope of this PR to try to refactor all of that (if it even is refactorable), so I left a comment in the codebase explaining all of the sources of features I could find.
[AIX] strip underlying xcoff object
When stripping, we need to strip the archive member first before archiving. Otherwise, the shared library remain untouched, only the archive symbol table will be modified.
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
Introduce `-Zmacro-stats`
Introduce `-Zmacro-stats`.
It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros.
r? `@petrochenkov`
Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code
Follow-up of https://github.com/rust-lang/rust/pull/141747.
Thanks `@camelid` for spotting it!
r? `@camelid`
Implement asymmetrical precedence for closures and jumps
I have been through a series of asymmetrical precedence designs in Syn, and finally have one that I like and is worth backporting into rustc. It is based on just 2 bits of state: `next_operator_can_begin_expr` and `next_operator_can_continue_expr`.
Asymmetrical precedence is the thing that enables `(return 1) + 1` to require parentheses while `1 + return 1` does not, despite `+` always having stronger precedence than `return` [according to the Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence). This is facilitated by `next_operator_can_continue_expr`.
Relatedly, it is the thing that enables `(return) - 1` to require parentheses while `return + 1` does not, despite `+` and `-` having exactly the same precedence. This is facilitated by `next_operator_can_begin_expr`.
**Example:**
```rust
macro_rules! repro {
($e:expr) => {
$e - $e;
$e + $e;
};
}
fn main() {
repro!{return}
repro!{return 1}
}
```
`-Zunpretty=expanded` **Before:**
```console
fn main() {
(return) - (return);
(return) + (return);
(return 1) - (return 1);
(return 1) + (return 1);
}
```
**After:**
```console
fn main() {
(return) - return;
return + return;
(return 1) - return 1;
(return 1) + return 1;
}
```
compiler: Ease off the accelerator on `unsupported_calling_conventions`
This is to give us more time to discuss rust-lang/rust#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps
I believe we should consider this a simple suspension of the decision in rust-lang/rust#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
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.
Closesrust-lang/rust-clippy#14692
The suggestion of `manual_flatten` does not includes the replacement of
`if let` so far despite of `.flatten()` suggestion.
This PR eliminates a redundant `if let`.
changelog: [`manual_flatten`] the suggestion removes `if let`
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#134536 (Lint on fn pointers comparisons in external macros)
- rust-lang/rust#141069 (Suggest mut when possbile for temporary value dropped while borrowed)
- rust-lang/rust#141934 (resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes)
- rust-lang/rust#142034 (Detect method not being present that is present in other tuple types)
- rust-lang/rust#142402 (chore(doctest): Remove redundant blank lines)
- rust-lang/rust#142406 (Note when enum variants shadow an associated function)
- rust-lang/rust#142407 (Remove bootstrap adhoc group)
- rust-lang/rust#142408 (Add myself (WaffleLapkin) to review rotation)
- rust-lang/rust#142418 (Remove lower_arg_ty as all callers were passing `None`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove bootstrap adhoc group
It corresponds 1:1 to the current bootstrap team, and with the new review preferences we shouldn't need it.
Discussed on Zulip.
r? ``@davidtwco``
Detect method not being present that is present in other tuple types
When a method is not present because of a trait bound not being met, and that trait bound is on a tuple, we check if making the tuple have no borrowed types makes the method to be found and highlight it if it does. This is a common problem for Bevy in particular and ORMs in general.
<img width="1166" alt="Screenshot 2025-06-04 at 10 38 24 AM" src="https://github.com/user-attachments/assets/d257c9ea-c2d7-42e7-8473-8b93aa54b8e0" />
Address rust-lang/rust#141258. I believe that more combination of cases in the tuple types should be handled (like adding borrows and checking when a specific type needs to not be a borrow while the rest stay the same), but for now this handles the most common case.
resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes
Unblocks https://github.com/rust-lang/rust/pull/139493.
Zulip thread requesting help - [#t-compiler/help > Help requested for effects of #139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911).
This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from https://github.com/rust-lang/rust/pull/139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`.
This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected.
(The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
Lint on fn pointers comparisons in external macros
This PR extends the recently stabilized `unpredictable_function_pointer_comparisons` lint ~~to also lint on `Option<{function pointer}>` and~~ as well as linting in external macros (as to catch `assert_eq!` and others).
```rust
assert_eq!(Some::<FnPtr>(func), Some(func as unsafe extern "C" fn()));
//~^ WARN function pointer comparisons
#[derive(PartialEq, Eq)]
struct A {
f: fn(),
//~^ WARN function pointer comparisons
}
```
Fixes https://github.com/rust-lang/rust/issues/134527
Infrastructure for lints during attribute parsing, specifically duplicate usages of attributes
r? `@oli-obk`
This PR adds a new field to OwnerInfo to buffer lints which are generated during attribute parsing and ast lowering in general. They can't be emitted at this stage because at that point there's no HIR yet, and early lints are already emitted.
This also adds the generic `S: Stage` to attribute parsers. Currently we don't emit any lints during early attribute parsing, but if we ever want to that logic will be different. That's because there we don't have hir ids yet, while at the same time still having access to node ids and early lints. Even though that logic isn't completely there in this PR (no worries, we don't use it), that's why the parameter is there.
With this PR, we also add 2 associated consts to `SingleAttributeParser`. Those determine what logic should be applied when finding a duplicate attribute.
This PR was getting pretty large, so the first code using this logic is in rust-lang/rust#138165. This code is all new things that weren't possible before so it also doesn't break any behaviour. However, some of it will be dead code right now. I recommend reviewing both before merging, though in some sense that doubles the size of the review again, and the other PR might be more controversial. Let me know how you want to do this `@oli-obk`
miri: add flag to suppress float non-determinism
We have flags controlling most non-determinism, so this seems generally useful for debugging. It is also needed to work around https://github.com/rust-lang/portable-simd/issues/463 in miri-test-libstd.
I made this a rustc PR so that it propagates faster to unbreak miri-test-libstd.
r? `@oli-obk`
Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations
## Motivation
The existing documentation for atomic `fetch_update` (and other similar methods) has a section that reads like so:
> ### Considerations
> This method is not magic; it is not provided by the hardware. It is implemented in
> terms of `AtomicBlah::compare_exchange_weak`, and suffers from the same drawbacks.
> In particular, this method will not circumvent the [ABA Problem].
>
> [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem
The wording here seems to imply that the drawbacks being discusses are caused by the *`weak` version* of `compare_exchange`, and that one may avoid those drawbacks by using `compare_exchange` instead. Indeed, a conversation in the `#dark-arts` channel on the Rust community discord based on this interpretation led to this PR.
In reality, the drawbacks are inherent to implementing such an operation based on *any* compare-and-swap style operation, as opposed to an [LL,SC](https://en.wikipedia.org/wiki/Load-link/store-conditional) operation, and they apply equally to `compare_exchange` and `compare_exchange_weak` as well.
## Changes
- Rewords existing Considerations section on `fetch_update` and friends to make clear that the limitations are inherent to an implementation based on any CAS operation, rather than the weak version of `compare_exchange` in particular. New version:
> ### Considerations
>
> This method is not magic; it is not provided by the hardware, and does not act like a
> critical section or mutex.
>
> It is implemented on top of an atomic [compare-and-swap operation], and thus is subject to
> the usual drawbacks of CAS operations. In particular, be careful of the [ABA problem]
> if this atomic integer is an index or more generally if knowledge of only the *bitwise value*
> of the atomic is not in and of itself sufficient to ensure any required preconditions.
>
> [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem
> [compare-and-swap operation]: https://en.wikipedia.org/wiki/Compare-and-swap
- Add Considerations to `compare_exchange` and `compare_exchange_weak` which details similar considerations and when they may be relevant. New version:
> ### Considerations
>
> `compare_exchange` is a [compare-and-swap operation] and thus exhibits the usual downsides
> of CAS operations. In particular, a load of the value followed by a successful
> `compare_exchange` with the previous load *does not ensure* that other threads have not
> changed the value in the interim. This is usually important when the *equality* check in
> the `compare_exchange` is being used to check the *identity* of a value, but equality
> does not necessarily imply identity. In this case, `compare_exchange` can lead to the
> [ABA problem].
>
> [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem
> [compare-and-swap operation]: https://en.wikipedia.org/wiki/Compare-and-swap
Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field.
Add that the enum must be `#[repr(Rust)]` and not `#[repr(packed)]` or `#[repr(align)]` in order to be ABI-compatible with its null-pointer-optimized field.
The specific rules here were decided on here: https://github.com/rust-lang/rust/pull/130628#issuecomment-2402761599 but `repr` was not mentioned. In practice, only `#[repr(Rust)]` (or no `repr` attribute, which is equivalent) works for this, so add that to the docs.
-----
Restrict to `#[repr(Rust)]` only, since:
* `#[repr(C)]` and the primitive representations (`#[repr(u8)]` etc) definitely disqualify the enum from NPO, since they have defined layouts that store the tag separately to the payload.
* `#[repr(transparent)]` enums are covered two bullet points above this (line 1830), and cannot have multiple variants, so would fail the "The enum has exactly two variants" requirement anyway.
As for `#[repr(align)]`: my current wording that it is completely disallowed may be too strong: it seems like `#[repr(align(<= alignment of T))] enum Foo { X, Y(T) }` currently does still have the same ABI as `T` in practice, though this may not be something we want to promise. (`#[repr(align(> alignment of T))]` definitely disqualifies the enum from being ABI-compatible with T currently).
I added the note about `packed` to match `align`, but `#[repr(packed)]` currently can't be applied to `enum`s at all anyway, so might be unnecessary.
-----
I think this needs T-lang approval?
cc ``````@workingjubilee``````
Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints
Best viewed commit by commit.
The first commit is a test, the commits following that are small refactors to `rustc_parse_format`. Originally I wanted to do a much larger change (doing these smaller fixes first would have that made easier to review), but ended up doing something else instead.
An observable change from this is that the diagnostic attribute no longer tries to parse align/fill/width/etc parameters. For an example (see also test changes), a string like `"{Self:!}"` no longer says "missing '}'", instead it says that format parameters are not allowed. It'll now also format the string as if the user wrote just `"{Self}"`
refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking
First commit changes the following:
- `AttributeGate ` from an enum with (four) tuple fields to (five) named fields
- adds a `notes` fields that is emitted as notes in the `PostExpansionVisitor` pass
- removes the `this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date` note if the feature gate is `rustc_attrs`.
- various phrasing changes and touchups
- and finally, the reason why I went down this path to begin with: tell people they can use the diagnostic namespace when they hit the rustc_on_unimplemented feature gate 🙈
Second commit removes unused machinery for deprecated attributes
