retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features
`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.
Also this PR forbids to specify those target features manually (warning).
Issue: rust-lang/rust#116852
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`
Apply nested goals certainty to `InspectGoals` for normalizes-to
...so that normalizes-to goals don't have `Certainty::Yes` even if they have nested goals which don't hold.
r? lcnr
Cleanup `rust-src` remapping and real dir
When remapping, `bootstrap` sets `CFG_VIRTUAL_RUST_SOURCE_BASE_DIR` to indicate what the base build dir (`/` of this repo) was remapped to, ie. `/rustc/...`.
It is therefore impossible when stripping `/rustc/...` from a remapped path to be inside the our `library/` directory, nevertheless we have code that assumed it was possible and helpfully tried to correct it. I don't why this was done, but it's not necessary.
~~The normalization in compiletest of `$SRC_DIR_REAL` was also slightly wrong, it ate the `library` part for no reason.~~ EDIT: there is a reason, it affects too much tests otherwise
r? `@jieyouxu`
Assorted bootstrap cleanups (step 1)
Now that the stage0 redesign has landed, we can finally start cleaning up many things in bootstrap, and lord knows it deserves it! I plan to send many PRs once I figure out an incremental way forward, this is the first one of them. It doesn't actually change anything, just renames stuff and adds more documentation, but the rename is bitrotty, so I wanted to push the PR eagerly.
r? `@jieyouxu`
`tests/ui`: A New Order [11/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
`tests/ui`: A New Order [10/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
rustc_resolve: Improve `resolve_const_param_in_non_trivial_anon_const` wording
In some contexts, const expressions are OK. Add a `here` to the error message to clarify this.
Closesrust-lang/rust#79429 which has 15 x 👍
More simple 2015 edition test decoupling
This should be the last of these PRs for now. The remaining tests that do not work on other editions than 2015 either need the range support (so blocked on the MCP), need normalization rules (which needs discussions first/same MCP) or revisions.
r? compiler-errors
transmutability: shift abstraction boundary
Previously, `rustc_transmute`'s layout representations were genericized over `R`, a reference. Now, it's instead genericized over representations of type and region. This allows us to move reference transmutability logic from `rustc_trait_selection` to `rustc_transmutability` (and thus unit test it independently of the compiler), and — in a follow-up PR — will make it possible to support analyzing function pointer transmutability with minimal surgery.
r? `@compiler-errors`
It's not clear to me how we ended up with the other order here --
hopefully this isn't an indicator of some form of instability in Cargo?
But either order is fine...
Faster fmt::Display of 128-bit integers, without unsafe pointer
In followup of #135265, hereby the 128-bit part.
* Batches per 16 instead of 19 digits
* Buffer access as array insteaf of unsafe pointer
* Added test coverage for i128 and u128
r? tgross35 ChrisDenton
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#142305 (Remove unneeded `check_id` calls as they are already called in `visit_id` in `EarlyContextAndPass` type)
- rust-lang/rust#142314 (remove ice group pings from `triagebot.toml`)
- rust-lang/rust#142343 (remove myself from the project)
- rust-lang/rust#142346 (Add tracing import to execution context)
- rust-lang/rust#142356 (Fix enter_trace_span!() using wrong $crate paths)
- rust-lang/rust#142362 (Add expectation for `{` when parsing lone coroutine qualifiers)
- rust-lang/rust#142364 (Do not warn on `rust.incremental` when using download CI rustc)
- rust-lang/rust#142369 (Improve some attribute docs and rename groups)
- rust-lang/rust#142374 (Fix missing newline trim in bootstrap)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve some attribute docs and rename groups
r? `@nnethercote`
Some naming here got changed at some point, and this feels more consistent. The docs changes were a direct response to `@mejrs` trying to implement a new parsers and running into this.
Matthias Krüger