[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
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.
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!
centralize `-Zmin-function-alignment` logic
tracking issue: https://github.com/rust-lang/rust/issues/82232
discussed in: https://github.com/rust-lang/rust/pull/142824#discussion_r2160056244
Apply the `-Zmin-function-alignment` value to the alignment field of the function attributes when those are created, so that individual backends don't need to consider it.
The one exception right now is cranelift, because it can't yet set the alignment for individual functions, but it can (and does) set the global minimum function alignment.
cc ``@RalfJung`` I think this is an improvement regardless, is there anything else that should be done for miri?
Skip no-op drop glue
Since rust-lang/rust#122662 this no longer gets used in vtables, so we're safe to fully
drop generating functions from vtables. Those are eventually cleaned up
by LLVM, but it's wasteful to produce them in the first place.
This doesn't appear to be a significant win (and shows some slight regressions) but
seems like the right thing to do. At minimum it reduces noise in the LLVM IR we generate,
which seems like a good thing.
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#142458 (Merge unboxed trait object error suggestion into regular dyn incompat error)
- rust-lang/rust#142593 (Add a warning to LateContext::get_def_path)
- rust-lang/rust#142594 (Add DesugaringKind::FormatLiteral)
- rust-lang/rust#142740 (Clean-up `FnCtxt::is_destruct_assignment_desugaring`)
- rust-lang/rust#142780 (Port `#[must_use]` to new attribute parsing infrastructure)
- rust-lang/rust#142798 (Don't fail to parse a struct if a semicolon is used to separate fields)
- rust-lang/rust#142856 (Add a few inline directives in rustc_serialize.)
- rust-lang/rust#142868 (remove few allow(dead_code))
- rust-lang/rust#142874 (cranelift: fix target feature name typo: "fxsr")
- rust-lang/rust#142877 (Document why tidy checks if `eslint` is installed via `npm`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add a few inline directives in rustc_serialize.
I see `debug_strict_add` and `debug_strict_sub` appearing in callgrind output. This bothers me. This PR should make them disappear.
Clean-up `FnCtxt::is_destruct_assignment_desugaring`
I noticed the docstring thing and fixed that; then I thought I'd rewrite the method using let-chains while I'm at it, since that seemed appropriate. But I don't feel too strongly about the second change, so let me know if I should remove it
Add DesugaringKind::FormatLiteral
Implements `DesugaringKind::FormatLiteral` to mark the FormatArgs desugaring of format literals. The main use for this is to stop yapping about about formatting parameters if we're not anywhere near a format literal. The other use case is to fix suggestions such as https://github.com/rust-lang/rust/issues/141350. It might also be useful for new or existing diagnostics that check whether they're in a format-like macro.
cc `@xizheyin` `@fmease`
Merge unboxed trait object error suggestion into regular dyn incompat error
Another hir-walker removed from the well-formed queries. This error was always a duplicate of another, but it was able to provide more information because it could invoke `is_dyn_compatible` without worrying about cycle errors. That's also the reason we can't put the error directly into hir_ty_lowering when lowering a `dyn Trait` within an associated item signature. So instead I packed it into the error handling of wf obligation checking.
completely deduplicate `Visitor` and `MutVisitor`
r? oli-obk
This closesrust-lang/rust#127615.
### Discussion
> * Give every `MutVisitor::visit_*` method a corresponding `flat_map_*` method.
Not every AST node exists in a location where they can be mapped to multiple instances of themselves. Not every AST node exists in a location where they can be removed from existence (e.g. `filter_map_expr`). I don't think this is doable.
> * Give every `MutVisitor::visit_*` method a corresponding `Visitor` method and vice versa
The only three remaining method-level asymmetries after this PR are `visit_stmt` and `visit_nested_use_tree` (only on `Visitor`) and `visit_span` (only on `MutVisitor`).
`visit_stmt` doesn't seem applicable to `MutVisitor` because `walk_flat_map_stmt_kind` will ask `flat_map_item` / `filter_map_expr` to potentially turn a single `Stmt` to multiple based on what a visitor wants. So only using `flat_map_stmt` seems appropriate.
`visit_nested_use_tree` is used for `rustc_resolve` to track stuff. Not useful for `MutVisitor` for now.
`visit_span` is currently not used for `MutVisitor` already, it was just kept in case we want to revive rust-lang/rust#127241. cc `@cjgillot` maybe we could remove for now and re-insert later if we find a use-case? It does involve some extra effort to maintain.
* Remaining FIXMEs
`visit_lifetime` has an extra param for `Visitor` that's not in `MutVisitor`. This is again something only used by `rustc_resolve`. I think we can keep that symmetry for now.
All HIR attributes are outer
Fixes https://github.com/rust-lang/rust/issues/142649. Closes https://github.com/rust-lang/rust/pull/142759.
All HIR attributes, including parsed and not yet parsed, will now be rendered as outer attributes by `rustc_hir_pretty`. The original style of the corresponding AST attribute(s) is not relevant for pretty printing, only for diagnostics.
r? ````@jdonszelmann````
