coverage: Build the expansion tree around `SyntaxContext`
The expansion tree was previously built around `ExpnId`, which was subtly incorrect in cases where multiple distinct syntax contexts share the same `outer_expn` ID. This can occur in the presence of nested macro expansions.
This change turns out to be fairly straightforward, because in all cases we were obtaining `ExpnId` from `span.ctxt().outer_expn()` anyway, so we can just remove the call to `.outer_expn()` and use the context instead.
As a result of this change, `context-mismatch-issue-147339.rs` no longer triggers a context mismatch in `extract_refined_covspans`, so this PR is a more principled fix for https://github.com/rust-lang/rust/issues/147339.
The expansion tree was previously built around `ExpnId`, which was subtly
incorrect in cases where multiple distinct syntax contexts share the same
`outer_expn` ID. This can occur in the presence of nested macro expansions.
This change turns out to be fairly straightforward, because in all cases we
were obtaining `ExpnId` from `span.ctxt().outer_expn()` anyway, so we can just
remove the call to `.outer_expn()` and use the context instead.
As a result of this change, `context-mismatch-issue-147339.rs` no longer
triggers a context mismatch in `extract_refined_covspans`.
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#156970 (coverage: Use original HIR info for synthetic by-move coroutine bodies)
- rust-lang/rust#157022 (MIR inlining: allow backends to opt-in to inlining intrinsics)
- rust-lang/rust#157026 (miri subtree update)
- rust-lang/rust#156390 (Constify Iterator-related methods and functions)
- rust-lang/rust#156845 (Clarify "infinite size" in cyclic-type diagnostic refers to the type name)
- rust-lang/rust#156955 (Fix const-eval of shared generic reborrows)
- rust-lang/rust#156973 (Add uwtable annotation to modules when required)
- rust-lang/rust#156985 (Limit the additional DLL to Windows)
- rust-lang/rust#156988 (interpret/validity: properly treat zero-variant enums so that we do not have to check layout.is_uninhabited)
- rust-lang/rust#157002 (std: Fix thread::available_parallelism on Redox targets)
interpret/validity: properly treat zero-variant enums so that we do not have to check layout.is_uninhabited
I am very happy to finally remove the last of these somewhat ad-hoc checks. :)
r? @oli-obk
Add uwtable annotation to modules when required
When unwind tables are enabled with `-Cforce-unwind-tables=y`, Rust will annotate all functions with the `uwtable` annotation. However, this annotation is missing on modules, which leads to incorrect unwind tables being generated by LLVM for constructors (such as `asan.module_ctor`).
This was discovered because it leads to a crash in Linux when KASAN and dynamic shadow call stack are both enabled. In this scenario, the kernel uses the unwind tables to locate the `paciasp` and `autiasp` instructions in each function and patches the machine code at boot to use the shadow call stack instructions instead. However, LLVM's AArch64PointerAuth pass emits DWARF info for `paciasp` whenever `-g` is passed, but only emits DWARF info for `autiasp` when the `uwtable` attribute is present. Since the `uwtable` annotation is missing for modules, the relevant directives are generated for only the `autiasp` instruction in `asan.module_ctor`, and not for the `paciasp` instruction. This causes the kernel's dynamic SCS logic to patch the prolouge of `asan.module_ctor`, but not the epilogue. This leads to a crash as the shadow call stack becomes unbalanced.
The fact that LLVM doesn't use the same condition for whether to emit DWARF information for both instructions may be a separate bug in LLVM.
Relevant issue: https://github.com/llvm/llvm-project/issues/188234
AI assistance was used to determine the root cause of this crash from the observed symptoms, and to write the tests. Also thanks to @samitolvanen and @maurer for debugging this issue.
Similar to this previous PR of mine: rust-lang/rust#130824
Fix const-eval of shared generic reborrows
`Rvalue::Reborrow` const-eval now handles shared generic reborrows produced by `CoerceShared`. Those reborrows intentionally copy from the source ADT into a distinct same-layout target ADT, so the interpreter uses the transmute-capable copy path for `Mutability::Not`.
Promotion is intentionally kept conservative: promotion candidates whose validated temporary graph contains `Rvalue::Reborrow` are rejected, so generic/user-defined reborrows are not promoted.
Fixesrust-lang/rust#156313.
cc @aapoalas
Tracking: rust-lang/rust#145612
@rustbot label F-reborrow
Clarify "infinite size" in cyclic-type diagnostic refers to the type name
Closesrust-lang/rust#149842
The `TypeError::CyclicTy` diagnostic currently emits
"cyclic type of infinite size". As discussed in the issue, "infinite
size" reads as the in-memory `size_of::<T>()` of values, when it
actually refers to the textual representation of the type name (an
iso-recursive occurs-check failure).
This rewords the message so the qualifier "infinite-size" clearly
modifies the *name*, matching the direction `@fmease`, `@BoxyUwU`,
and the issue author converged on:
```
- cyclic type of infinite size
+ recursive type with infinite-size name
```
Nine existing UI `.stderr` baselines and two `//~ NOTE` annotations
are updated to track the new wording. No semantics change.
Tested:
- ./x test tests/ui/const-generics/occurs-check/ tests/ui/closures/ tests/ui/unboxed-closures/ tests/ui/typeck/ tests/ui/coroutine/ --force-rerun
- ./x test tidy
MIR inlining: allow backends to opt-in to inlining intrinsics
This is the same as https://github.com/rust-lang/rust/pull/156398. Github stopped processing updates on that other branch.
r? @oli-obk
coverage: Use original HIR info for synthetic by-move coroutine bodies
> This is a copy of #156952(because my git was acting weird)
Synthetic by-move coroutine bodies created for async closures don't have useful HIR of their own. Coverage was falling back to the parent async closure for HIR info, which means the executed `AsyncFnOnce` body could inherit hole spans from the wrong body and report the user-written closure body as uncovered.
This PR uses the synthetic body's coroutine type to recover the original coroutine body def-id, then extracts HIR info from that body instead. That keeps the coverage spans tied to the body the synthetic MIR was cloned from.
Fixesrust-lang/rust#151135.
r? Zalathar
Merge several HIR-level queries into one
Now four queries (`local_def_id_to_hir_id`, `opt_hir_owner_nodes`, `opt_ast_lowering_delayed_lints`, `in_scope_traits_map`) were replaced with regular methods which acts like getters.
An `hir_owner` query was added that returns a `ProjectedMaybeOwner` that contains all those fields. `hir_attr_map` remains a separate query as adding attributes to `ProjectedMaybeOwner` led to [perf regressions](https://github.com/rust-lang/rust/pull/155678#issuecomment-4304597871).
There is a similar issue with `in_scopes_trait_map`, but according to the comments from https://github.com/rust-lang/rustc-perf/pull/2436 it is a rare case.
Most of the changes in incremental tests are renames from `opt_hir_owner_nodes` -> `hir_owner`, but there are few cases when new dirty queries were added.
r? @petrochenkov
r? @oli-obk
Add missing --set rust.codegen-backends=["gcc"] in the gcc codegen Dockerfile for the core tests
The CI would use cranelift instead of the gcc codegen.
This fixes it and was tested in rust-lang/rust#156964.
r? @Kobzol
cc @GuillaumeGomez
add field_projections fixme
haven't looked at the code in detail, but I can't see a way in which this is the correct behavior. I think ideally `try_evaluate_added_goals` just doens't return the certainty as afaik it only does so because `evaluate_added_goals_and_make_canonical_response` uses it internally
r? @Nadrieril @BennoLossin
Remove unneeded `#[skip_arg]` attributes
@mejrs talked with me about the `Diagnostic` rework that happened recently and suggested that the `skip_arg` might be unneeded. This PR removes all of them, except one. I'll run a perf check to see if it's actually worth keeping around or if we can just remove this attribute altogether (or eventually do the same thing in the proc-macro directly).
cc @JonathanBrouwer
r? ghost
Extend macOS deployment target mismatch filter to cover dylib and new ld formats
The `deployment_mismatch` filter in `report_linker_output` only matched the old ld64 format for object files. With linker-messages promoted to warn-by-default in rust-lang/rust#153968, unfiltered deployment target warnings from dylibs and the new Apple linker (ld_prime) now surface as noise for users who never set `MACOSX_DEPLOYMENT_TARGET`.
Fixesrust-lang/rust#156714.
At present, the filter works only covered the specific format:
`ld: warning: object file (...) was built for newer 'macOS' version (...) than being linked (...)`
This was fine because linker-messages was `Allow-by-default` — nobody saw the other formats anyway. Then rust-lang/rust#153968 promoted it to Warn, and the gaps became visible.
Broadens the filter to cover all known ld deployment target version mismatch formats:
`ld: warning: object file (...)` — old ld64, already handled
`ld: warning: dylib (...)` — old ld64, was missing
All Apple platforms (`iOS`, `tvOS`, `watchOS`, `xrOS`, etc.), not just `macOS`
`ld: building for <platform>-A.B, but linking with dylib '...' which was built for newer version C.D` — new linker (ld_prime, Xcode 15+), the exact format from rust-lang/rust#156714
All matched messages are downgraded to `linker_info` (Allow-by-default), consistent with the existing behavior for the object file case.
fix issue-144595
I close the previous PR because it's too messy
relevant issue:rust-lang/rust#144595
I fix this issue by calling `look_ahead` to check if the user write a name field in the tuple struct, then try to recover after calling `parse_ty`
rustc_parse_format: improve the error diagnostic for `+` sign flag
Added a new parser diagnostic in rustc_parse_format that detects when the `+` sign flag is used without a preceding colon in a format string (e.g., `{+}`) and provides a helpful error message and suggestion to use `{:+}` instead.
r? estebank
Update cargo submodule
13 commits in 4d1f984518c77fad6eeef4f40153b002a659e662..fbb61be30e5f9ac3a6ad58e56a5c0f5db2d2b3ef
2026-05-15 17:12:01 +0000 to 2026-05-26 15:08:03 +0000
- fix(compiler): forward verbose flag to rustc for local crates (rust-lang/cargo#17006)
- Fix CVE-2026-5222 and CVE-2026-5223 (rust-lang/cargo#17031)
- Don't use the network for a publish dry-run test (rust-lang/cargo#17027)
- feat: Break out `RegistryConfig` and `crate_url` for interpreting `RegistryConfig::dl` (rust-lang/cargo#17011)
- refactor(diag): Sort the PARSE_PASS_RULES (rust-lang/cargo#17019)
- fix(artifact)!: Remove compat mode from artifacts (rust-lang/cargo#17016)
- refactor(diag): Simplify adding of new diagnostics (rust-lang/cargo#17015)
- test(package): Mark a network test that timed out on me (rust-lang/cargo#17017)
- refactor(diag): Pull in the parse pass (rust-lang/cargo#17008)
- test(lints): Avoid compiling where possible (rust-lang/cargo#17007)
- fix(diag): Report deferred diagnostics like other diagnostics (rust-lang/cargo#16994)
- refactor: drop `-Zunstable-options` for `rustdoc --emit` (rust-lang/cargo#17002)
- chore(deps): update msrv (1 version) to v1.95 (rust-lang/cargo#17001)
std::net::tcp: let the OS pick the port numbers
See rust-lang/rust#156377 for context.
I only did the TCP tests for now to see whether there are any unexpected problems.
Jonathan Brouwer