Allow `global_asm!` in statement positions
This PR makes it possible to put `global_asm!` in statement positions. This is particularly useful for proc-macros, where you otherwise have to wrap them in `mod foo { global_asm!(...); }`.
I'm happy to open an ACP first (or a design meeting?).
I would also assume this needs sign-off from the lang-team?
Previously discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/216763-project-inline-asm/topic/Item.20position.20global_asm/with/581784943).
r? @Amanieu
Preserve spans when hiding do_not_recommend impls
Fixesrust-lang/rust#156475 by restoring the root span only when the current refined span has wandered outside the parent obligation.
Fix cross-compiling `macos-deployment-target-warning` test
`cc()` gets target flags, which won't match with the host triple used by `bare_rustc()`.
Follow-up to https://github.com/rust-lang/rust/pull/155716, with both of these, `./x test --target arm64e-apple-darwin tests` now succeeds.
r? compiler
Avoid rustfix suggestions for macro-expanded unused imports
Avoid emitting rustfix suggestions for unused imports when the removal span is not directly editable.
Closesrust-lang/rust#147855
explicit tail calls: ignore some tests on unsupported LLVM targets
Fixes https://github.com/rust-lang/rust/issues/148748
Add ignore derivatives to two tests that cause the most platforms to fail, there are two reasons:
All tests involving `musttail` should fail on these platforms due to poor support overall by LLVM, but since they have low usage and supposedly already have many tests failing we limit ignores to the two "worst" tests.
```
//@ ignore-aix
//@ ignore-csky
//@ ignore-mips
//@ ignore-mips64
//@ ignore-powerpc
//@ ignore-powerpc64
//@ ignore-thumb
```
aix/powerpc issue: https://github.com/llvm/llvm-project/issues/187119
thumb issue: https://github.com/llvm/llvm-project/issues/73167
mips has been fixed but it is in a different LLVM version than what is pinned by Rust: https://github.com/llvm/llvm-project/issues/57795
These were caused by argument/returns that do not fit in registers (e.g., indirect), they had a fix but were reverted due to lifetime issues:
```
//@ ignore-riscv64
//@ ignore-loongarch32
//@ ignore-loongarch64
```
RISC-V had a fix which got reverted: https://github.com/llvm/llvm-project/pull/191508
LoongArch fix also got reverted: https://github.com/llvm/llvm-project/pull/191525
Also add missing compiletest directive names for `ignore-csky`, `ignore-mips`, and `ignore-mips64`.
r? folkertdev
Test EII UI tests with prefer-dynamic
Tracking issue: rust-lang/rust#125418
Remove `no-prefer-dynamic` from the EII UI tests now that rust-lang/rust#153648 fixed exporting EII declaration aliases from dylibs.
Fixesrust-lang/rust#151271.
Tested with:
```sh
python3 x.py test tests/ui/eii --force-rerun
```
compiler: suggest `.collect()` when `String` is expected and `Iterator` is found
This commit adds a diagnostic suggestion to help users who forget to call `.collect()` when they have an iterator and the function or variable expects a `String`.
The logic checks if the expected type is `std::string::String` and if the found type implements the `Iterator` trait, if so the compiler provides a suggestion to add `.collect()`
Includes also a UI test to verify if the suggestion appears correctly
Remove redundant information in `rustc_abi::Variants`
Follow-up to rust-lang/rust#151040; partially addresses rust-lang/rust#113988.
Replaces the nested `LayoutData` in `Variants::Multiple` by a new, smaller `VariantLayout` struct, and adjust `LayoutData::for_variant`and the layout algorithm in consequence.
This PR is best reviewed commit-by-commit.
[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
rustdoc: properly support macros with multiple kinds
Since it seems like I can't reopen https://github.com/rust-lang/rust/pull/145458, opening this one. Although, it's the same PR minus the last new commit to handle a comment that was left unresolved in the original PR. All relevant details are still in the original PR though.
It's an alternative (and likely a take-over) of https://github.com/rust-lang/rust/pull/148005 since lang-team rejected the idea to add documentation on macro branches, making the multiple files approach less suitable.
This implements rust-lang/rust#145153 in rustdoc. This PR voluntarily doesn't touch anything related to intra-doc links, I'll send a follow-up if needed.
So now about the implementation itself: this is a weird case where a macro can be different things at once but still only gets one file generated. I saw two ways to implement this:
1. Handle `ItemKind::Macro` differently and iter through its `MacroKinds` values.
2. Add new placeholder variants in the `ItemKind` enum, which means that when we encounter them in rendering, we need to ignore them. It also makes the `ItemKind` enum bigger (and also needs more code to be handled). Another downside is that it needs to be handled in the JSON output.
Now there was an interesting improvement that came with this PR in the `html::render::print_item::item_module` function: I simplified its implementation and split the different parts in a `HashMap` where the key is the item type. So then, we can just iterate through the keys and open/close the section at each iteration instead of keeping an `Option<section>` around.
From RFCs:
* https://github.com/rust-lang/rust/pull/144579
* https://github.com/rust-lang/rust/pull/145208
derive:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-40" src="https://github.com/user-attachments/assets/f69587a0-8a2b-4080-bc8a-b63dd18f21c1" />
attr:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-31" src="https://github.com/user-attachments/assets/bf9b235a-9d2f-435c-a91e-167562df6b68" />
both:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-50" src="https://github.com/user-attachments/assets/b7e8b3c6-eb99-495b-bdf9-17ba8fb4da0d" />
r? @notriddle
coverage: Reduce and clarify the context-mismatch test case
Most of the complexity in this test case isn't needed to reproduce the condition observed in https://github.com/rust-lang/rust/issues/147339.
I have checked that this reduced test case still triggers the context-mismatch in `extract_refined_covspans`.
Correctly handle associated items in rustdoc macro expansion
Fixesrust-lang/rust#156075.
The bug was simply that it didn't cover associated items.
r? @Urgau
delegation: emit error when self type is not specified and accessed
This PR adds error reporting when we create error self type if it was not specified. In most of the tests there were other errors, so this delayed bug was not triggered, but there are cases like `reuse Default::default;` (rust-lang/rust#156388) which does not emit other errors and those delayed bugs are triggered.
Part of rust-lang/rust#118212. Fixesrust-lang/rust#156388.
r? @petrochenkov
Allow user-provided `llvm_args` to override target spec arguments
This switches the order in which `-Cllvm-args` is applied between target-spec arguments and user-provided LLVM arguments.
This came up in rust-lang/rust#156061, where the target passing `-Cllvm-args=-wasm-use-legacy-eh=false` means that a user passing `-Cllvm-args=-wasm-use-legacy-eh=true` cannot override this value since the LLVM arguments support the last argument overriding the previous, and user arguments were chained first.
With this change, it is possible for Wasm targets to opt into legacy EH for compatibility with runtimes that don't yet implement the modern exnref/try_table instructions, such as Node.js 20 on V8 11.3 and older browsers. While Node.js 20 is formally EOL, many libraries will still need to support this version for a few months yet, so this would ease the transition path to modern exception handling having an opt-out.
Originally this PR added support for a dedicated `-Z` flag for switching to legacy exception handling, but fine-grained control over the arguments would be a preferable solution provided it does not conflict with other behaviours.
//cc @alexcrichton
Implement pinned drop sugar
Implements `fn drop(&pin mut self)` as sugar for `Drop::pin_drop`.
The resolver recognizes `fn drop(&pin mut self)` syntactically in trait impls and performs lookup using the effective `pin_drop` name. AST lowering independently rechecks the syntactic sugar, validates that the resolved item belongs to the actual `Drop` lang trait, and emits HIR with ident `pin_drop` for accepted sugar. Existing type checking, Drop validation, drop glue, and direct-call checks remain unchanged.
Drop identity is checked during AST lowering through `tcx.lang_items().drop_trait()`, after resolver has performed the effective `pin_drop` lookup. The resolver does not need to know whether the trait is the actual `Drop` lang item, and it no longer passes marked impl item IDs to lowering.
This intentionally preserves the base pinned-drop behavior where `#[pin_v2]` types must use `pin_drop`, while non-`#[pin_v2]` types may still implement `pin_drop`.
r? @petrochenkov
## Related
https://github.com/rust-lang/rust/pull/144537https://github.com/rust-lang/rust/issues/130494
Require EIIs to be defined when we compile a rust dylib
The linker will complain about undefined symbols otherwise and on object file formats with two level namespaces (Mach-O and PE/COFF) it is required to know which dylib a symbol will be imported from when linking a dylib or executable.
r? @jdonszelmann
The linker will complain about undefined symbols otherwise and on object
file formats with two level namespaces (Mach-O and PE/COFF) it is
required to know which dylib a symbol will be imported from when linking
a dylib or executable.
Jonathan Brouwer