`cargo fix` does not have a way of distinguishing a suggestion with
multiple spans which should all be applied from multiple suggestions
where only one should be applied (see issue 53934). `cargo fix` only
works with `MachineApplicable` suggestions, so downgrading the
applicability will stop `cargo` from suggesting the user run `cargo
fix`. rust-analyzer does work with `MaybeIncorrect`, so interactive
fixes are still available.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140005 (Set MSG_NOSIGNAL for UnixStream)
- rust-lang/rust#140622 (compiletest: Improve diagnostics for line annotation mismatches)
- rust-lang/rust#142354 (Fixes firefox copy paste issue)
- rust-lang/rust#142695 (Port `#[rustc_skip_during_method_dispatch]` to the new attribute system)
- rust-lang/rust#142779 (Add note about `str::split` handling of no matches.)
- rust-lang/rust#142894 (phantom_variance_markers: fix identifier usage in macro)
- rust-lang/rust#142928 (Fix hang in --print=file-names in bootstrap)
- rust-lang/rust#142932 (rustdoc-json: Keep empty generic args if parenthesized)
- rust-lang/rust#142933 (Simplify root goal API of solver a bit)
r? `@ghost`
`@rustbot` modify labels: rollup
Simplify root goal API of solver a bit
Root goal API is more easily distinguished between proof tree and non-proof tree, rather than `eval_goal` vs `eval_goal_raw`.
r? lcnr
Fix hang in --print=file-names in bootstrap
In an interactive context, the subprocess inherited a real tty stdin, which lead it it waiting for something to happen, even though nothing happened. By explicitly passing null as stdin we make sure an empty file is passed, which achieves the desired behavior.
Fixesrust-lang/rust#142926 (verified locally by cherry-picking the patch onto beta where I was building).
phantom_variance_markers: fix identifier usage in macro
This shouldn't have worked originally, as far as we can tell.
Fixes an implementation detail of rust-lang/rust#135806.
compiletest: Improve diagnostics for line annotation mismatches
When some line annotations are missing or misplaced, compiletest reports an error, but the error is not very convenient.
This PR attempts to improve the user experience.
- The "expected ... not found" messages are no longer duplicated.
- The `proc_res.status` and `proc_res.cmdline` message is no longer put in the middle of other messages describing the annotation mismatches, it's now put into the end.
- Compiletest now makes suggestions if there are fuzzy matches between expected and actually reported errors (e.g. the annotation is put on a wrong line).
- Missing diagnostic kinds are no longer produce an error eagerly, but instead treated as always mismatching kinds, so they can produce suggestions telling the right kind.
I'll post screenshots in the thread below, but the behavior shown on the screenshots can be reproduced locally using the new test `tests/ui/compiletest-self-test/line-annotation-mismatches.rs`.
This also fixes https://github.com/rust-lang/rust/issues/140940.
r? ``@jieyouxu``
Account for beta revisions when normalizing versions
Several UI tests have a `normalize-stderr` for "you are using x.y.z"
rustc versions, and that regex is flexible enough for suffixes like
"-nightly" and "-dev", but not for "-beta.N". We can just add '.' to
that trailing pattern to include this.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140985 (Change `core::iter::Fuse`'s `Default` impl to do what its docs say it does)
- rust-lang/rust#141324 (std: sys: random: uefi: Provide rdrand based fallback)
- rust-lang/rust#142134 (Reject unsupported `extern "{abi}"`s consistently in all positions)
- rust-lang/rust#142784 (Add codegen timing section)
- rust-lang/rust#142827 (Move error code explanation removal check into tidy)
- rust-lang/rust#142873 (Don't suggest changing a method inside a expansion)
- rust-lang/rust#142908 (Fix install-template.sh for Solaris tr)
- rust-lang/rust#142922 (Fix comment on NoMangle)
- rust-lang/rust#142923 (fix `-Zmin-function-alignment` on functions without attributes)
r? `@ghost`
`@rustbot` modify labels: rollup
Because in the case of for example
pub fn my_fn3(f: impl FnMut()) {}
we want to keep `()` even if it is empty since that matches e.g. Rust
syntax requirements.
Several UI tests have a `normalize-stderr` for "you are using x.y.z"
rustc versions, and that regex is flexible enough for suffixes like
"-nightly" and "-dev", but not for "-beta.N". We can just add '.' to
that trailing pattern to include this.
fix `-Zmin-function-alignment` on functions without attributes
tracking issue: https://github.com/rust-lang/rust/issues/82232
related: https://github.com/rust-lang/rust/pull/142854
The minimum function alignment was skipped on functions without attributes (because the logic was in a loop that only runs if there is at least one attribute). The underlying reason we didn't catch this before is that in our testing we generally apply `#[no_mangle]` to functions that are tested. I've added a test now that deliberately has no attributes.
r? `@workingjubilee`
Add codegen timing section
And since we now start and end the sections also using separate functions, also add some light checking if we're generating the sections correctly.
I'm integrating `--timings` into Cargo, and I realized that the codegen timings would be quite useful for that. Frontend can be computed simply as `[start of compilation, start of codegen]` for now.
r? `@nnethercote`
Reject unsupported `extern "{abi}"`s consistently in all positions
Modify the handling of `extern "{abi}"` in the compiler so that it has consistent errors without regard to the position in the grammar.
## What
Implement the following breakages:
- Promote [`unsupported_fn_ptr_calling_conventions`] from a warning to a hard error
- Guarantee future edge-cases like trait declarations will not escape so that *ABIs that have already been unusable in most positions* will now be unusable in **all positions**. See "How" and "Why or Why Not" for more details.
In particular, these architecture-specific ABIs now only compile on their architectures[^4]:
- amdgpu: "gpu-kernel"
- arm: "aapcs", "C-cmse-nonsecure-entry", "C-cmse-nonsecure-call"
- avr: "avr-interrupt", "avr-non-blocking-interrupt"
- msp430: "msp430-interrupt"
- nvptx64: "gpu-kernel", "ptx-kernel"
- riscv32 and riscv64: "riscv-interrupt-m", "riscv-interrupt-s"
- x86: "thiscall"
- x86 and x86_64: "x86-interrupt"
- x86_64: "sysv64", "win64"
ABIs that are logically x86-specific but actually permitted on all Windows targets remain permitted on Windows, as before. For non-Windows targets, they error if we had previously done so in other positions.
## How
We modify rustc_ast_lowering to prevent unsupported ABIs from leaking through the HIR without being checked for target support. They now emit hard errors for every case where we would return `Invalid` from `AbiMap::canonize_abi`. Previously ad-hoc checking on various HIR items required making sure we check every HIR item which could contain an `extern "{abi}"` string. This is a losing proposition compared to gating the lowering itself.
As a consequence, unsupported ABI strings error instead of triggering the warning `unsupported_fn_ptr_calling_conventions`. The code is also simpler compared to alternative implementations that might e.g. split on unstable vs. stable, only suffering some unavoidable complication to support the newly-revived `unsupported_calling_conventions` lint.[^5]
However, per rust-lang/rust#86232 this does cause errors for rare usages of `extern "{abi}"` that were theoretically possible to write in Rust source, without previous warning or error. For instance, trait declarations without impls were never checked. These are the exact kinds of leakages that this new approach prevents.
This differs from the following PRs:
- rust-lang/rust#141435 is orthogonal, as it adds a new lint for ABIs we have not warned on and are not touched by this PR
- rust-lang/rust#141877 is subsumed by this, in that this simply cuts out bad functionality instead of adding epicycles for stable code
## Why or Why Not
We already made the decision to issue the `unsupported_fn_ptr_calling_conventions` future compatibility warning. It has warned in dependencies since rust-lang/rust#135767, which reached stable with Rust 1.87. That was released on 2025 May 17, and it is now June. As we already had erred on these ABI strings in most other positions, and warn on stable for function pointer types, this breakage has had reasonable foreshadowing.
Upgrading the warning to an error addresses a real problem. In some cases the Rust compiler can attempt to actually compute the ABI for calling a function with an unsupported ABI. We could accept this case and compute unsupported ABIs according to some other ABI, silently[^6]. However, this obviously exposes Rust to errors in codegen. We cannot lower directly to the "obvious", target-incorrect ABI and then trust code generators like LLVM to reliably error on these cases, either.
Other considerations include:
- We could refactor the compiler to defer ABI computations, but that seems like it would suffer the "whack-a-mole" problem close to linking instead of after parsing and expansion.
- We could run a deprecation cycle for the edge cases, but we would be warning highly marginal cases, like this trait declaration without a definition that cannot be implemented without error[^9].
```rust
pub trait UsedToSneakBy {
pub extern "gpu-kernel" fn sneaky();
}
```
- The [crater run] on this PR's draft form suggests the primary issue is with implementations on function pointers, which has already been warned on, so it does not seem like we would be benefiting any real code.
- Converting this to a hard error now, in the same cycle that we ship the reanimation of the `unsupported_calling_conventions` lint, means people who would otherwise have to deal with two lints only have to update their code in one batch. Of course, one of them is as breakage.
r? lang
Fixesrust-lang/rust#86232Fixesrust-lang/rust#132430Fixesrust-lang/rust#138738Fixesrust-lang/rust#142107
[`unsupported_fn_ptr_calling_conventions`]: https://github.com/rust-lang/rust/issues/130260
[crater run]: https://github.com/rust-lang/rust/pull/142134#issuecomment-2953837506
[^9]: Upon any impl, even for provided fn within trait declarations, e.g. `pub extern "gpu-kernel" fn sneaky() {}`, different HIR types were used which would, in fact, get checked. Likewise for anything with function pointers. Thus we would be discussing deprecation cycles for code that is impotent or forewarned[^7].
[^4]: Some already will not compile, due to reaching ICEs or LLVM errors.
[^5]: That lint cannot be moved in a similar way yet because lints operate on HIR, so you cannot emit lints when the HIR has not been completely formed.
[^6]: We already do this for all `AbiStr` we cannot parse, pretending they are `ExternAbi::Rust`, but we also emit an error to prevent reaching too far into codegen.
[^7]: It actually did appear in two cases in rustc's test suite because we are a collection of Rust edge-cases by the simple fact that we don't care if the code actually runs. These cases are being excised in 643a9d233b
Change `core::iter::Fuse`'s `Default` impl to do what its docs say it does
The [docs on `impl<I: Default> Default for core::iter::Fuse<I>`](https://doc.rust-lang.org/nightly/std/iter/struct.Fuse.html#impl-Default-for-Fuse%3CI%3E) say (as the `I: Default` bound implies) that `Fuse::<I>::default` "Creates a `Fuse` iterator from the default value of `I`". However, the implementation creates a `Fuse` with `Fuse { iter: Default::default() }`, and since the `iter` field is an `Option<I>`, this is actually `Fuse { iter: None }`, not `Fuse { iter: Some(I::default()) }`, so `Fuse::<I>::default()` always returns an empty iterator, even if `I::default()` would not be empty.
This PR changes `Fuse`'s `Default` implementation to match the documentation. This will be a behavior change for anyone currently using `Fuse::<I>::default()` where `I::default()` is not an empty iterator[^1], as `Fuse::<I>::default()` will now also not be an empty iterator.
(Alternately, the docs could be updated to reflect what the current implementation actually does, i.e. returns an always-exhausted iterator that never yields any items (even if `I::default()` would have yielded items). With this option, the `I: Default` bound could also be removed to reflect that no `I` is ever created.)
[Current behavior example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a1e0adc4badca3dc11bfb70a99213249) (maybe an example like this should be added to the docs either way?)
This PR changes publicly observable behavior, so I think requires at least a T-libs-api FCP?
r? libs-api
cc https://github.com/rust-lang/rust/issues/140961
`impl<I: Default> Default for Fuse<I>` was added in 1.70.0 (https://github.com/rust-lang/rust/pull/99929), and it's docs and behavior do not appear to have changed since (`Fuse`'s `iter` field has been an `Option` since before the impl was added).
[^1]: IIUC it is a "de facto" guideline for the stdlib that an iterator type's `default()` should be empty (and for iterators where that would not make sense, they should not implement `Default`): cc https://github.com/rust-lang/libs-team/issues/77#issuecomment-1194681709 , so for stdlib iterators, I don't think this would change anything. However, if a user has a custom `Iterator` type `I`, *and* they are using `Fuse<I>`, *and* they call `Fuse::<I>::default()`, this may change the behavior of their code.
In an interactive context, the subprocess inherited a real tty stdin,
which lead it it waiting for something to happen, even though nothing
happened. By explicitly passing null as stdin we make sure an empty file
is passed, which achieves the desired behavior.
the minimum function alignment was skipped on functions without attributes. That is because in our testing we generally apply `#[no_mangle]` to functions that are tested. I've added a test now that deliberately has no attributes
We have fairly different error messages now and handle more cases,
so we augment the test in tests/ui/abi/unsupported.rs with more examples
to handle structs, traits, and impls on same when those feature
the unsupported ABIs of interest.
We modify rustc_ast_lowering to prevent all unsupported ABIs
from leaking through the HIR without being checked for target support.
Previously ad-hoc checking on various HIR items required making sure
we check every HIR item which could contain an `extern "{abi}"` string.
This is a losing proposition compared to gating the lowering itself.
As a consequence, unsupported ABI strings will now hard-error instead of
triggering the FCW `unsupported_fn_ptr_calling_conventions`.
This FCW was upgraded to warn in dependencies in Rust 1.87 which was
released on 2025 May 17, and it is now 2025 June, so it has become
active within a stable Rust version.
As we already had errored on these ABIs in most other positions, and
have warned for fn ptrs, this breakage has had reasonable foreshadowing.
However, this does cause errors for usages of `extern "{abi}"` that were
theoretically writeable within source but could not actually be applied
in any useful way by Rust programmers without either warning or error.
For instance, trait declarations without impls were never checked.
These are the exact kinds of leakages that this new approach prevents.
A deprecation cycle is not useful for these marginal cases as upon impl,
even default impls within traits, different HIR objects would be used.
Details of our HIR analysis meant that those objects did get checked.
We choose to error twice if an ABI is also barred by a feature gate
on the presumption that usage of a target-incorrect ABI is intentional.
Co-authored-by: Ralf Jung <post@ralfj.de>
Fix ICE on debug builds where lints are delayed on the crate root
r? ``@oli-obk``
Closesrust-lang/rust#142891
thanks to ``@JonathanBrouwer`` for finding it!
