about summary refs log tree commit diff
path: root/tests/ui/repr
AgeCommit message (Collapse)AuthorLines
2023-11-27Detect and reject malformed repr(Rust) hintsLeón Orell Valerian Liehr-8/+35
2023-11-24Show number in error message even for one errorNilstrieb-2/+2
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-10-23Update `since` stability attributes in testsDavid Tolnay-3/+3
2023-10-23Fix stable feature names in testsDavid Tolnay-3/+3
2023-10-18Make `#[repr(Rust)]` and `#[repr(C)]` incompatible with one anotherLeón Orell Valerian Liehr-0/+62
2023-10-05Add a note to duplicate diagnosticsAlex Macleod-0/+16
2023-09-25Gate and validate #[rustc_safe_intrinsic]León Orell Valerian Liehr-1/+1
2023-09-19Don't complain on a single non-exhaustive 1-zstMichael Goulet-1/+81
2023-08-29repr(transparent): it's fine if the one non-1-ZST field is a ZSTRalf Jung-44/+61
2023-08-20Clarify that `Rust` is default reprCatherine Flores-5/+5
2023-07-29Allow explicit `#[repr(Rust)]`Catherine Flores-5/+5
2023-07-21error/E0691: include alignment in error messageDavid Rheinsberg-4/+4
Include the computed alignment of the violating field when rejecting transparent types with non-trivially aligned ZSTs. ZST member fields in transparent types must have an alignment of 1 (to ensure it does not raise the layout requirements of the transparent field). The current error message looks like this: LL | struct Foobar(u32, [u32; 0]); | ^^^^^^^^ has alignment larger than 1 This patch changes the report to include the alignment of the violating field: LL | struct Foobar(u32, [u32; 0]); | ^^^^^^^^ has alignment of 4, which is larger than 1 In case of unknown alignments, it will yield: LL | struct Foobar<T>(u32, [T; 0]); | ^^^^^^ may have alignment larger than 1 This allows developers to get a better grasp why a specific field is rejected. Knowing the alignment of the violating field makes it easier to judge where that alignment-requirement originates, and thus hopefully provide better hints on how to mitigate the problem. This idea was proposed in 2022 in #98071 as part of a bigger change. This commit simply extracts this error-message change, to decouple it from the other diagnostic improvements.
2023-05-01Don't bail out early when checking invalid `repr` attrclubby789-1/+24
2023-04-21Migrate `rustc_hir_analysis` to session diagnosticObei Sideg-1/+3
Part 4: Finishing `check/mod.rs` file
2023-02-16Default repr(C) enums to c_int sizeJubilee Young-0/+52
This is what ISO C strongly implies this is correct, and many processor-specific ABIs imply or mandate this size, so "everyone" (LLVM, gcc...) defaults to emitting enums this way. However, this is by no means guaranteed by ISO C, and the bare-metal Arm targets show it can be overridden, which rustc supports via `c-enum-min-bits` in a target.json. The override is a flag named `-fshort-enums` in clang and gcc, but introducing a CLI flag is probably unnecessary for rustc. This flag can be used by non-Arm microcontroller targets, like AVR and MSP430, but it is not enabled for them by default. Rust programmers who know the size of a target's enums can use explicit reprs, which also lets them match C23 code. This change is most relevant to 16-bit targets: AVR and MSP430. Most of rustc's targets use 32-bit ints, but ILP64 does exist. Regardless, rustc should now correctly handle enums for both very small and very large targets. Thanks to William for confirming MSP430 behavior, and to Waffle for better style and no-core size_of asserts. Co-authored-by: William D. Jones <thor0505@comcast.net> Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>
2023-01-11Move /src/test to /testsAlbert Larsan-0/+1281