about summary refs log tree commit diff
path: root/tests/ui/layout
AgeCommit message (Collapse)AuthorLines
2025-08-06Print thread ID in panic message if thread name is unknownTrevor Gross-1/+1
`panic!` does not print any identifying information for threads that are unnamed. However, in many cases, the thread ID can be determined. This changes the panic message from something like this: thread '<unnamed>' panicked at src/main.rs:3:5: explicit panic To something like this: thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5: explicit panic Stack overflow messages are updated as well. This change applies to both named and unnamed threads. The ID printed is the OS integer thread ID rather than the Rust thread ID, which should also be what debuggers print.
2025-07-25Check statics' type in type_of.Camille GILLOT-22/+1
2025-07-20Consider parent predicates in ImpossiblePredicates pass.Camille GILLOT-16/+14
2025-07-16trait_sel: `MetaSized` always holds temporarilyDavid Wood-10/+2
As a temporary measure while a proper fix for `tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs` is implemented, make `MetaSized` obligations always hold. In effect, temporarily reverting the `sized_hierarchy` feature. This is a small change that can be backported.
2025-07-04Rollup merge of #143296 - Kivooeo:tf21, r=tgross35Jubilee-0/+122
`tests/ui`: A New Order [21/N] > [!NOTE] > > Intermediate commits are intended to help review, but will be squashed prior to merge. Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895. r? `@tgross35`
2025-07-05cleaned up some testsKivooeo-24/+38
2025-07-05moved testsKivooeo-0/+108
2025-06-30Unconditionally run `check_item_type` on all itemsOli Scherer-27/+27
2025-06-16tests: update tests with unconstrained parametersDavid Wood-3/+12
With the addition of new bounds to the unconstrained parameters, there are more errors which just need blessed.
2025-06-12intrinsics: rename min_align_of to align_ofRalf Jung-1/+1
2025-06-09Auto merge of #142220 - workingjubilee:rollup-idgfpof, r=workingjubileebors-149/+75
Rollup of 12 pull requests Successful merges: - rust-lang/rust#141803 (Remove rustc's notion of "preferred" alignment AKA `__alignof`) - rust-lang/rust#142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`) - rust-lang/rust#142089 (Replace all uses of sysroot_candidates with get_or_default_sysroot) - rust-lang/rust#142108 (compiler: Add track_caller to AbiMapping::unwrap) - rust-lang/rust#142132 (`tests/ui`: A New Order [6/N]) - rust-lang/rust#142162 (UnsafePinned: update get() docs and signature to allow shared mutation) - rust-lang/rust#142171 (`tests/ui`: A New Order [7/N]) - rust-lang/rust#142179 (store `target.min_global_align` as an `Align`) - rust-lang/rust#142183 (Added test for 30904) - rust-lang/rust#142194 (Remove all unused feature gates from the compiler) - rust-lang/rust#142199 (Do not free disk space in the `mingw-check-tidy` job) - rust-lang/rust#142210 (Run `mingw-check-tidy` on auto builds) r? `@ghost` `@rustbot` modify labels: rollup
2025-06-08Remove rustc's notion of "preferred" alignment AKA `__alignof`Jubilee Young-149/+75
In PR 90877 T-lang decided not to remove `intrinsics::pref_align_of`. However, the intrinsic and its supporting code 1. is a nightly feature, so can be removed at compiler/libs discretion 2. requires considerable effort in the compiler to support, as it necessarily complicates every single site reasoning about alignment 3. has been justified based on relevance to codegen, but it is only a requirement for C++ (not C, not Rust) stack frame layout for AIX, in ways Rust would not consider even with increased C++ interop 4. is only used by rustc to overalign some globals, not correctness 5. can be adequately replaced by other rules for globals, as it mostly affects alignments for a few types under 16 bytes of alignment 6. has only one clear benefactor: automating C -> Rust translation for GNU extensions like `__alignof` 7. such code was likely intended to be `alignof` or `_Alignof`, because the GNU extension is a "false friend" of the C keyword, which makes the choice to support such a mapping very questionable 8. makes it easy to do incorrect codegen in the compiler by its mere presence as usual Rust rules of alignment (e.g. `size == align * N`) do not hold with preferred alignment The implementation is clearly damaging the code quality of the compiler. Thus it is within the compiler team's purview to simply rip it out. If T-lang wishes to have this intrinsic restored for c2rust's benefit, it would have to use a radically different implementation that somehow does not cause internal incorrectness. Until then, remove the intrinsic and its supporting code, as one tool and an ill-considered GCC extension cannot justify risking correctness. Because we touch a fair amount of the compiler to change this at all, and unfortunately the duplication of AbiAndPrefAlign is deep-rooted, we keep an "AbiAlign" type which we can wean code off later.
2025-06-07const-eval error: always say in which item the error occurredRalf Jung-7/+7
also adjust the wording a little so that we don't say "the error occurred here" for two different spans
2025-06-02Clarify why we are talking about a failed const eval at a random placeOli Scherer-6/+6
2025-06-02Use the informative error as the main const eval error messageOli Scherer-21/+26
2025-05-07Remove manual WF hackMichael Goulet-10/+38
2025-04-13UI tests: migrate remaining compile time `error-pattern`s to line annotationsVadim Petrochenkov-3/+3
when possible.
2025-04-08UI tests: add missing diagnostic kinds where possibleVadim Petrochenkov-1/+1
2025-04-03compiletest: Require `//~` annotations even if `error-pattern` is specifiedVadim Petrochenkov-4/+4
2025-03-30Auto merge of #138206 - ↵bors-1/+25
amy-kwan:amy-kwan/reprc-struct-power-align-ignore-packed-align, r=workingjubilee [AIX] Ignore linting on repr(C) structs with repr(packed) or repr(align(n)) This PR updates the lint added in 9b40bd7 to ignore repr(C) structs that also have repr(packed) or repr(align(n)). As these representations can be modifiers on repr(C), it is assumed that users that add these should know what they are doing, and thus the the lint should not warn on the respective structs. For example, for the time being, using repr(packed) and manually padding a repr(C) struct can be done to correctly align struct members on AIX.
2025-03-11Implement `#[define_opaque]` attribute for functions.Oli Scherer-15/+16
2025-03-08Refactor coroutine layout logic to precompute all sublayoutsMoulins-7/+1
Also properly attaches spans on layouts of non-promoted coroutine locals, which slightly improves the error messages for some coroutine tests.
2025-03-08[AIX] Ignore linting on repr(C) structs with repr(packed) or repr(align(n))Amy Kwan-1/+25
This PR updates the lint added in 9b40bd7 to ignore repr(C) structs that also have repr(packed) or repr(align(n)). As these representations can be modifiers on repr(C), it is assumed that users that add these should know what they are doing, and thus the the lint should not warn on the respective structs. For example, for the time being, using repr(packed) and manually padding a repr(C) struct can be done to correctly align struct members on AIX.
2025-03-06Rollup merge of #137805 - RalfJung:layout-debug-print, r=NoratriebMichael Goulet-74/+74
adjust Layout debug printing to match the internal field name The field got renamed a while ago, but the debug printing was not updated to match.
2025-03-03Don't typeck during WF, instead check outside of WF in check_crateMichael Goulet-9/+9
2025-03-01Rollup merge of #136503 - estebank:const-panic, r=RalfJungMatthias Krüger-15/+7
Tweak output of const panic diagnostic ### Shorten span of panic failures in const context Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown. ``` error[E0080]: evaluation of constant value failed --> $DIR/assert-type-intrinsics.rs:11:9 | LL | MaybeUninit::<!>::uninit().assume_init(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ panic: aborted execution: attempted to instantiate uninhabited type `!` ``` ``` error[E0080]: evaluation of `Fail::<i32>::C` failed --> $DIR/collect-in-dead-closure.rs:9:19 | LL | const C: () = panic!(); | ^^^^^^^^ explicit panic | = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) ``` ``` error[E0080]: evaluation of constant value failed --> $DIR/uninhabited.rs:87:9 | LL | assert!(false); | ^^^^^^^^^^^^^^ assertion failed: false | = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info) ``` ### Remove duplicated span from const eval frame list When the primary span for a const error is the same as the first frame in the const error report, skip it. ``` error[E0080]: evaluation of constant value failed --> $DIR/issue-88434-removal-index-should-be-less.rs:3:24 | LL | const _CONST: &[u8] = &f(&[], |_| {}); | ^^^^^^^^^^^^^^ explicit panic | note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>` --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5 | LL | panic!() | ^^^^^^^^ the failure occurred here = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) ``` instead of ``` error[E0080]: evaluation of constant value failed --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5 | LL | panic!() | ^^^^^^^^ explicit panic | note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>` --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5 | LL | panic!() | ^^^^^^^^ note: inside `_CONST` --> $DIR/issue-88434-removal-index-should-be-less.rs:3:24 | LL | const _CONST: &[u8] = &f(&[], |_| {}); | ^^^^^^^^^^^^^^ = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) note: erroneous constant encountered --> $DIR/issue-88434-removal-index-should-be-less.rs:3:23 | LL | const _CONST: &[u8] = &f(&[], |_| {}); | ^^^^^^^^^^^^^^^ ``` r? ``@oli-obk``
2025-02-28Shorten span of panic failures in const contextEsteban Küber-15/+7
Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown. ``` error[E0080]: evaluation of constant value failed --> $DIR/assert-type-intrinsics.rs:11:9 | LL | MaybeUninit::<!>::uninit().assume_init(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation panicked: aborted execution: attempted to instantiate uninhabited type `!` ``` ``` error[E0080]: evaluation of `Fail::<i32>::C` failed --> $DIR/collect-in-dead-closure.rs:9:19 | LL | const C: () = panic!(); | ^^^^^^^^ evaluation panicked: explicit panic | = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) ``` ``` error[E0080]: evaluation of constant value failed --> $DIR/uninhabited.rs:41:9 | LL | assert!(false); | ^^^^^^^^^^^^^^ evaluation panicked: assertion failed: false | = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info) ``` --- When the primary span for a const error is the same as the first frame in the const error report, skip it. ``` error[E0080]: evaluation of constant value failed --> $DIR/issue-88434-removal-index-should-be-less.rs:3:24 | LL | const _CONST: &[u8] = &f(&[], |_| {}); | ^^^^^^^^^^^^^^ evaluation panicked: explicit panic | note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>` --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5 | LL | panic!() | ^^^^^^^^ the failure occurred here = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) ``` instead of ``` error[E0080]: evaluation of constant value failed --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5 | LL | panic!() | ^^^^^^^^ explicit panic | note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>` --> $DIR/issue-88434-removal-index-should-be-less.rs:10:5 | LL | panic!() | ^^^^^^^^ note: inside `_CONST` --> $DIR/issue-88434-removal-index-should-be-less.rs:3:24 | LL | const _CONST: &[u8] = &f(&[], |_| {}); | ^^^^^^^^^^^^^^ = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) ``` --- Revert order of constant evaluation errors Point at the code the user wrote first and std functions last. ``` error[E0080]: evaluation of constant value failed --> $DIR/const-errs-dont-conflict-103369.rs:5:25 | LL | impl ConstGenericTrait<{my_fn(1)}> for () {} | ^^^^^^^^ evaluation panicked: Some error occurred | note: called from `my_fn` --> $DIR/const-errs-dont-conflict-103369.rs:10:5 | LL | panic!("Some error occurred"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) ``` instead of ``` error[E0080]: evaluation of constant value failed --> $DIR/const-errs-dont-conflict-103369.rs:10:5 | LL | panic!("Some error occurred"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some error occurred | note: called from `<() as ConstGenericTrait<{my_fn(1)}>>::{constant#0}` --> $DIR/const-errs-dont-conflict-103369.rs:5:25 | LL | impl ConstGenericTrait<{my_fn(1)}> for () {} | ^^^^^^^^ = note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info) ```
2025-02-28adjust Layout debug printing to match the internal field namesRalf Jung-74/+74
2025-02-24tests: use minicore moreDavid Wood-20/+21
minicore makes it much easier to add new language items to all of the existing `no_core` tests.
2025-02-21don't leave assoc const unnormalized due to unconstrained paramsLukas Markeffsky-2/+2
2025-02-21layout_of: put back not-so-unreachable caseLukas Markeffsky-0/+77
2025-02-20Update ui tests with `LayoutData { uninhabited: ... }` etcZachary S-1/+77
2025-02-18clean up layout error diagnosticsLukas Markeffsky-2/+2
- group the fluent slugs together - reword (internal-only) "too generic" error to be more in line with the other errors
2025-02-18document and test all `LayoutError` variantsLukas Markeffsky-1/+81
2025-02-13Implement and use BikeshedGuaranteedNoDrop for union/unsafe field validityMichael Goulet-2/+16
2025-01-27Add `TooGeneric` variant to `LayoutError` and emit `Unknown` oneFedericoBruzzone-8/+127
- `check-pass` test for a MRE of #135020 - fail test for #135138 - switch to `TooGeneric` for checking CMSE fn signatures - switch to `TooGeneric` for compute `SizeSkeleton` (for transmute) - fix broken tests
2025-01-23Rollup merge of #135552 - ↵Matthias Krüger-0/+264
amy-kwan:amy-kwan/reprc-struct-diagnostic-power-alignment, r=workingjubilee [AIX] Lint on structs that have a different alignment in AIX's C ABI This PR adds a linting diagnostic on AIX for repr(C) structs that are required to follow the power alignment rule. A repr(C) struct needs to follow the power alignment rule if the struct: - Has a floating-point data type (greater than 4-bytes) as its first member, or - The first member of the struct is an aggregate, whose recursively first member is a floating-point data type (greater than 4-bytes). The power alignment rule for eligible structs is currently unimplemented, so a linting diagnostic is produced when such a struct is encountered.
2025-01-22[AIX] Lint on structs that have a different alignment in AIX's C ABIAmy Kwan-0/+264
2025-01-16Properly note when query stack is being cut offMichael Goulet-1/+1
2025-01-14Consider more erroneous layouts as LayoutError::ReferencesError to suppress ↵Michael Goulet-14/+3
spurious errors
2025-01-10test that coercions still work under randomizationThe 8472-8/+40
2025-01-10exclude unsizable tail from randomization seed calculationThe 8472-3/+4
2025-01-10adjust UI testsThe 8472-40/+120
2025-01-10Foo<T> != Foo<U> under layout randomizationThe 8472-0/+29
previously field ordering was using the same seed for all instances of Foo, now we pass seed values through the layout tree so that not only the struct itself affects layout but also its fields
2025-01-01Try to write the panic message with a single `write_all` callJohn Kåre Alsaker-0/+1
2024-12-27Remove the `-test` suffix from normalize directivesZalathar-12/+12
2024-12-13Stabilize async closuresMichael Goulet-4/+2
2024-12-10Rollup merge of #134010 - RalfJung:promoted-type-error-ice, r=oli-obkLeón Orell Valerian Liehr-6/+0
fix ICE on type error in promoted Fixes https://github.com/rust-lang/rust/issues/133968 Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.
2024-12-09fix ICE on type error in promotedRalf Jung-6/+0
2024-12-07Mention type parameter in more cases and don't suggest ~const bound already ↵Esteban Küber-5/+5
there