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
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
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
codegen: re-enable FileCheck for scalable-vector tuple intrinsics
The FileCheck directives in `tests/codegen-llvm/scalable-vectors/tuple-intrinsics.rs` were not actually being checked: the test used `//@ build-pass`, and rust-lang/rust#155630 made that explicit by replacing it with `//@ skip-filecheck`.
This fixes the stale checks and re-enables FileCheck for the test. The `get` and `set` cases now use concrete index-0 wrappers, so they have stable `#[no_mangle]` names for FileCheck to match.
Fixesrust-lang/rust#155665.
r? @jieyouxu
tests: fix pub-priv-dep test expectation
Related to private dependencies rust-lang/rust#44663
The test had wrongly configured dependency privacy. The ascii graph shows that both dependencies should be private. Furthermore, the way this test existed was effectively identical to `shared_direct_private.rs`.
compiletest: Simplify `//@ needs-asm-mnemonic: ret` to just `//@ needs-asm-ret`
- Simplification of https://github.com/rust-lang/rust/pull/155692.
---
The `needs-asm-mnemonic` directive was very general, but in practice was only being used for `ret`. There are very few other mnemonics that it could plausibly be useful for (e.g. `nop`), because any instruction that requires arguments is probably going to be non-portable.
This PR replaces `needs-asm-mnemonic` with a simpler `needs-asm-ret` directive that uses the same machinery as other simple needs directives.
If we happend to need more mnemonics in the future, we can just add more simple directives as appropriate (e.g. `needs-asm-nop`).
The `needs-asm-mnemonic` directive was very general, but in practice was only
being used for `ret`. There are very few other mnemonics that it could
plausibly be useful for (e.g. `nop`), because any instruction that requires
arguments is probably going to be non-portable.
This PR replaces `needs-asm-mnemonic` with a simpler `needs-asm-ret` directive
that uses the same machinery as other simple needs directives.
If we happend to need more mnemonics in the future, we can just add more simple
directives as appropriate (e.g. `needs-asm-nop`).
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
Disable `tests/debuginfo/numeric-types.rs` `v nz_{i,u}size` checks
On lldb 22 (locally lldb 22.1.6) I see
```
v nz_isize
error: Invalid type: Cannot determine size
[...]
v nz_usize
error: Invalid type: Cannot determine size
```
AFAICT this might be an upstream issue, as reported in <https://github.com/llvm/llvm-project/issues/196812>. Let's disable for now to not have `./x test` fail for contributors using lldb 22. Tracked in rust-lang/rust#156886.
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
On lldb 22 (locally lldb 22.1.6) I see
```
v nz_isize
error: Invalid type: Cannot determine size
[...]
v nz_usize
error: Invalid type: Cannot determine size
```
AFAICT this might be an upstream issue, as reported in
<https://github.com/llvm/llvm-project/issues/196812>. Let's disable for
now to not have `./x test` fail for contributors using lldb 22.
Make impl_trait_redundant_captures suggestion remove adjacent +
Closesrust-lang/rust#143216
The `impl_trait_redundant_captures` lint's machine-applicable suggestion only
spanned the `use<...>` syntax itself, leaving the adjacent `+` joiner behind.
Applying the suggestion produced uncompilable code, e.g.
`impl Sized + use<>` becoming `impl Sized + ` (stray trailing `+`).
This extends the removal span to also cover one adjacent `+`, preserving
valid syntax in the three bound-list positions covered by the regression test:
- `impl Sized + use<>` becomes `impl Sized`
- `impl use<> + Sized` becomes `impl Sized`
- `impl Sized + use<> + Send` becomes `impl Sized + Send`
A `//@ run-rustfix` UI test exercises all three positions, so the
rustfix-applied output is actually compiled — covering the gap the
existing `redundant.rs` test left (which only checks lint firing, not
suggestion correctness).
Tested:
- ./x test tests/ui/impl-trait/precise-capturing/redundant-machine-applicable.rs --bless
- ./x test tidy
Add regression test for const parameter default ICE
Closesrust-lang/rust#142913
This adds a UI regression test for a fixed ICE where a const generic parameter
type mentioned an earlier lifetime and also had a default value.
The reproducer is the minimized version posted in the issue.
Tested:
- ./x test tests/ui/const-generics/generic_const_parameter_types/region-parameter-out-of-range-ice-142913.rs --force-rerun
- ./x test tidy --bless
Matthias Krüger