Emit a single error when importing a path with `_`
When encountering `use _;`, `use _::*'` or similar, do not emit two errors for that single mistake. This also side-steps the issue of resolve errors suggesting adding a crate named `_` to `Cargo.toml`.
Fixrust-lang/rust#142662.
mbe: Clean up code with non-optional `NonterminalKind`
Since [rust-lang/rust#128425], the fragment specifier is unconditionally required in all
editions. This means `NonTerminalKind` no longer needs to be optional,
as we can reject this code during the expansion of `macro_rules!` rather
than handling it throughout the code. Do this cleanup here.
[rust-lang/rust#128425]: https://github.com/rust-lang/rust/pull/128425
Also emit suggestions for usages in the `non_upper_case_globals` lint
This PR adds suggestions for all the usages of the renamed item in the warning of the `non_upper_case_globals` lint.
Fixes https://github.com/rust-lang/rust/issues/124061
```
error[E0382]: borrow of moved value: `x`
--> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
|
LL | let x = "Hello world!".to_string();
| - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL | thread::spawn(move || {
| ------- value moved into closure here
LL | println!("{}", x);
| - variable moved due to use in closure
LL | });
LL | println!("{}", x);
| ^ value borrowed here after move
|
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
|
LL ~ let value = x.clone();
LL ~ thread::spawn(move || {
LL ~ println!("{}", value);
|
```
When encountering `use _;`, `use _::*'` or similar, do not emit two errors for that single mistake. This also side-steps the issue of resolve errors suggesting adding a crate named `_` to `Cargo.toml`.
The version string is difficult to properly normalize out, and removing
it isn't a huge deal (the user can query version info easily through
`rustc --version` or `cargo --version`).
The normalization options were all non-ideal:
- Per-test version string normalization is nasty to maintain, and we
need to maintain `n` copies of it.
- Centralized compiletest normalization (with a directive opt-out) is
also not ideal, because `cfg(version(..))` tests can't have those
accidentally normalized out (and you'd have to remember to opt-out).
[win][aarch64] Fix linking statics on Arm64EC, take 2
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
Fixesrust-lang/rust#138541
Resurrects rust-lang/rust#140176 now that rust-lang/rust#141061 is merged, which removes the incompatibility with `__rust_no_alloc_shim_is_unstable`.
r? ``@wesleywiser``
CC ``@bjorn3``
Remove the deprecated unstable `concat_idents!` macro
In [rust-lang/rust#137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595 ("Add #concat_idents[] and
#ident_to_str[]"). The syntax looks a bit different but it still works
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://github.com/rust-lang/rust/issues/29599
[rust-lang/rust#137653]: https://github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://github.com/rust-lang/rust/issues/124225
In [137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595 ("Add #concat_idents[] and
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://www.github.com/rust-lang/rust/issues/29599
[137653]: https://www.github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://www.github.com/rust-lang/rust/issues/124225
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
Since [1], the fragment specifier is unconditionally required in all
editions. This means `NonTerminalKind` no longer needs to be optional,
as we can reject this code during the expansion of `macro_rules!` rather
than handling it throughout the code. Do this cleanup here.
[1]: https://github.com/rust-lang/rust/pull/128425
To make it match `-Zmacro-stats`, and work better if you have enabled it
for multiple crates.
- Print each crate's name.
- Print a `===` banner at the start and end for separation.
Currently they have the largest items at the end. I believe the
rationale is that it saves you scrolling up through terminal output
because the important stuff is at the bottom. But it's also surprising
and a bit confusing, and I think the obvious order (big things at the
top) is better.
Taking inspiration from `-Zmacro-stats`:
- Use "{prefix}" consistently.
- Use names for column widths.
- Write output in a single `eprint!` call, in an attempt to minimize
interleaving of output from different rustc processes.
- Use `repeat` for the long `---` banners.
It currently reports net size, i.e. size(output) - size(input). After
some use I think this is sub-optimal, and it's better to just report
size(output). Because for derive macros the input size is always 1, and
for attribute macros it's almost always 1.
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`
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 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!
