Suggest adding quotation marks to identifiers in attributes
When the user provides an identifier when a literal was expected in an attribute value, suggest adding quotation marks to the identifier to make it a string literal.
For instance:
```
error: attribute value must be a literal
--> $DIR/crate-type-non-crate.rs:9:16
|
LL | #[crate_type = lib]
| ^^^ help: try adding quotation marks: `"lib"`
```
Add `TypeId` methods `variants` `fields` `field` for `type_info`
Tracking issue rust-lang/rust#146922
- Adds `fn TypeId::variants` returns the number of variants, for struct and union and primitive types, it's always 1.
- Adds `fn TypeId::fields` returns the number of fields.
- Adds `fn TypeId::field` returns a field representing type `FieldId`.
- Adds a new type `FieldId`, which is a wrapper of `FieldRepresentingType`'s `TypeId`.
For methods `{fields,field}`, if indexing out of bounds, a compile-time error will be raised.
Regarding the removal of `Type` items, this will be done in a later PR in one go.
r? @oli-obk
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 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
fix E0371 description
This changes the `impl`s to be `impl {Trait} for dyn {Trait}` instead of just `impl {Trait} for {Trait}` in the description of E0371.
(While this was not part of "Crafting errors like rustc" workshop at RustWeek by @jdonszelmann and @estebank, I found this while going through all errors Rust emits to pick a favourite)
rustc_on_unimplemented: introduce format specifiers
...as printing options for the annotated item.
See also the test and dev guide prose. This only affects rustc_on_unimplemented, not (yet) the other diagnostic attributes. I plan to do that in some later PR.
```rust
#![feature(rustc_attrs)]
#[rustc_on_unimplemented(
message = "normal: {This}, path: {This:path}, resolved: {This:resolved}"
)]
pub trait Trait<'lifetime, const CONST_GENERIC: usize, A, B> where A: Send {}
```
will do:
```
normal: Trait, path: Trait<'lifetime, CONST_GENERIC, A, B>, resolved: Trait<'_, 6, u8, _>
```
delegation: remove method call generation
This PR removes method call generation from delegations, now we always generate default call. Part of rust-lang/rust#118212.
We reuse methods probing engine for finding needed adjustments, thus extending number of supported cases. In this PR adjustments are applied to trait methods (was supported before) ~and static functions (new feature)~. Free functions can be supported later.
Finally this PR solves issues from parent generics propagation from rust-lang/rust#155906.
r? @petrochenkov
Suppress garbled suggestions from strict provenance lints in macros
The strict provenance lints (`lossy_provenance_casts`, `fuzzy_provenance_casts`) build suggestions using span arithmetic (`shrink_to_lo()`, `shrink_to_hi()`, `.to()`). When the cast sits inside a macro, those span operations produce broken output like `$e as ).addr()` because the spans don't map cleanly back to source text.
The fix wraps suggestion fields in `Option` and checks `can_be_used_for_suggestions()` before constructing them. The lint itself still fires, you just don't get the garbled suggestion. Same approach already used in `op.rs` and `static_mut_refs.rs` in this crate.
### What changed
- `errors.rs`: `sugg` fields in `LossyProvenanceInt2Ptr` and `LossyProvenancePtr2Int` are now `Option<...>`
- `cast.rs`: suggestion construction in both `lossy_provenance_ptr2int_lint` and `fuzzy_provenance_int2ptr_lint` is guarded behind `can_be_used_for_suggestions()`
- New regression test confirms both lints fire on casts inside macros, with no suggestion block in output
Fixesrust-lang/rust#156850
Remove useless -Zunpretty=identified option
The `-Zunpretty=identified` option (without `expanded`) is effectively useless because `NodeId`s are unassigned prior to macro expansion, leading them to just be `NodeId::MAX_AS_U32`.
This commit removes the `Identified` variant from `PpSourceMode` and removes `-Zunpretty=identified` from the command-line options. Users should use `-Zunpretty=expanded,identified` instead (which is retained) if they want to inspect `NodeId`s.
Fixesrust-lang/rust#10671
Fix suggestion of unused variables with raw identifier in struct pattern
This MR fixes a broken lint suggestion that occurs when a struct pattern contains an unused variable written with a raw identifier.
In the following fragment, `r#move` is an unused variable. The compiler suggested to change it to `move: _` which doesn’t compile since move is a keyword. This change makes it so that the suggestion becomes `r#move: _`
```rust
struct Foo {
r#move: u32
}
fn bar(foo: Foo) -> u32 {
match foo {
Foo { r#move } => 0
}
}
```
r? JonathanBrouwer
Matthias Krüger