summary refs log tree commit diff
path: root/compiler/rustc_middle/src/ty/layout.rs
AgeCommit message (Collapse)AuthorLines
2023-09-23Remove GeneratorWitness and rename GeneratorWitnessMIR.Camille GILLOT-1/+0
2023-09-19rustc_target/riscv: Fix passing of transparent unions with only one non-ZST ↵msizanoen-0/+4
member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes https://github.com/rust-lang/rust/issues/115481.
2023-08-28Don't ICE on layout computation failureKatherine Philip-1/+9
2023-08-08feat: `riscv-interrupt-{m,s}` calling conventionsSeth Pellegrino-0/+2
Similar to prior support added for the mips430, avr, and x86 targets this change implements the rough equivalent of clang's [`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling e.g. ```rust static mut CNT: usize = 0; pub extern "riscv-interrupt-m" fn isr_m() { unsafe { CNT += 1; } } ``` to produce highly effective assembly like: ```asm pub extern "riscv-interrupt-m" fn isr_m() { 420003a0: 1141 addi sp,sp,-16 unsafe { CNT += 1; 420003a2: c62a sw a0,12(sp) 420003a4: c42e sw a1,8(sp) 420003a6: 3fc80537 lui a0,0x3fc80 420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0> 420003ae: 0585 addi a1,a1,1 420003b0: 62b52e23 sw a1,1596(a0) } } 420003b4: 4532 lw a0,12(sp) 420003b6: 45a2 lw a1,8(sp) 420003b8: 0141 addi sp,sp,16 420003ba: 30200073 mret ``` (disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`) This outcome is superior to hand-coded interrupt routines which, lacking visibility into any non-assembly body of the interrupt handler, have to be very conservative and save the [entire CPU state to the stack frame][full-frame-save]. By instead asking LLVM to only save the registers that it uses, we defer the decision to the tool with the best context: it can more accurately account for the cost of spills if it knows that every additional register used is already at the cost of an implicit spill. At the LLVM level, this is apparently [implemented by] marking every register as "[callee-save]," matching the semantics of an interrupt handler nicely (it has to leave the CPU state just as it found it after its `{m|s}ret`). This approach is not suitable for every interrupt handler, as it makes no attempt to e.g. save the state in a user-accessible stack frame. For a full discussion of those challenges and tradeoffs, please refer to [the interrupt calling conventions RFC][rfc]. Inside rustc, this implementation differs from prior art because LLVM does not expose the "all-saved" function flavor as a calling convention directly, instead preferring to use an attribute that allows for differentiating between "machine-mode" and "superivsor-mode" interrupts. Finally, some effort has been made to guide those who may not yet be aware of the differences between machine-mode and supervisor-mode interrupts as to why no `riscv-interrupt` calling convention is exposed through rustc, and similarly for why `riscv-interrupt-u` makes no appearance (as it would complicate future LLVM upgrades). [clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v [full-frame-save]: https://github.com/esp-rs/esp-riscv-rt/blob/9281af2ecffe13e40992917316f36920c26acaf3/src/lib.rs#L440-L469 [implemented by]: https://github.com/llvm/llvm-project/blob/b7fb2a3fec7c187d58a6d338ab512d9173bca987/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp#L61-L67 [callee-save]: https://github.com/llvm/llvm-project/blob/973f1fe7a8591c7af148e573491ab68cc15b6ecf/llvm/lib/Target/RISCV/RISCVCallingConv.td#L30-L37 [rfc]: https://github.com/rust-lang/rfcs/pull/3246
2023-08-01Use upvar_tys in more places, make it a listMichael Goulet-1/+1
2023-07-30inline format!() args up to and including rustc_middleMatthias Krüger-2/+2
2023-07-27Don't attempt to compute layout of type referencing errorMichael Goulet-2/+7
2023-07-25interpret: refactor projection code to work on a common trait, and use that ↵Ralf Jung-2/+2
for visitors
2023-07-21Revert "Auto merge of #113166 - moulins:ref-niches-initial, r=oli-obk"David Tolnay-265/+21
This reverts commit 557359f92512ca88b62a602ebda291f17a953002, reversing changes made to 1e6c09a803fd543a98bfbe1624d697a55300a786.
2023-07-21Track (partial) niche information in `NaiveLayout`Moulins-10/+48
Still more complexity, but this allows computing exact `NaiveLayout`s for null-optimized enums, and thus allows calls like `transmute::<Option<&T>, &U>()` to work in generic contexts.
2023-07-21Add doc-comments for `NaiveLayout`Moulins-12/+26
2023-07-21Track ABI info. in `NaiveLayout`, and use it for `PointerLike` checksMoulins-31/+126
THis significantly complicates `NaiveLayout` logic, but is necessary to ensure that bounds like `NonNull<T>: PointerLike` hold in generic contexts. Also implement exact layout computation for structs.
2023-07-21Track exactness in `NaiveLayout` and use it for `SizeSkeleton` checksMoulins-7/+29
2023-07-21Don't treat ref. fields with non-null niches as `dereferenceable_or_null`Moulins-21/+28
2023-07-21recover null-ptr optimization by adding a special case to the niching logicMoulins-0/+1
2023-07-21add `naive_layout_of` queryMoulins-0/+67
2023-07-15Auto merge of #112157 - erikdesjardins:align, r=nikicbors-0/+2
Resurrect: rustc_target: Add alignment to indirectly-passed by-value types, correcting the alignment of byval on x86 in the process. Same as #111551, which I [accidentally closed](https://github.com/rust-lang/rust/pull/111551#issuecomment-1571222612) :/ --- This resurrects PR #103830, which has sat idle for a while. Beyond #103830, this also: - fixes byval alignment for types containing vectors on Darwin (see `tests/codegen/align-byval-vector.rs`) - fixes byval alignment for overaligned types on x86 Windows (see `tests/codegen/align-byval.rs`) - fixes ABI for types with 128bit requested alignment on ARM64 Linux (see `tests/codegen/aarch64-struct-align-128.rs`) r? `@nikic` --- `@pcwalton's` original PR description is reproduced below: Commit 88e4d2c from five years ago removed support for alignment on indirectly-passed arguments because of problems with the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I recently added to LLVM 16 depend on this to forward `memcpy`s. This commit attempts to fix the problems with `byval` parameters on that target and now correctly adds the `align` attribute. The problem is summarized in [this comment] by `@eddyb.` Briefly, 32-bit x86 has special alignment rules for `byval` parameters: for the most part, their alignment is forced to 4. This is not well-documented anywhere but in the Clang source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate it here. The relevant methods in that file are `X86_32ABIInfo::getIndirectResult()` and `X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute for `byval` parameters in LLVM must match the platform ABI, or miscompilations will occur. Note that this doesn't use the approach suggested by eddyb, because I felt it was overkill to store the alignment in `on_stack` when special handling is really only needed for 32-bit x86. As a side effect, this should fix #80127, because it will make the `align` parameter attribute for `byval` parameters match the platform ABI on LLVM x86-64. [this comment]: #80822 (comment)
2023-07-14i686-windows: make requested alignment > 4 special case apply transitivelyErik Desjardins-1/+1
2023-07-14refactor(rustc_middle): Substs -> GenericArgMahdi Dibaiee-12/+11
2023-07-10aarch64-linux: properly handle 128bit aligned aggregatesErik Desjardins-0/+1
2023-07-10repr(align) <= 4 should still be byvalErik Desjardins-1/+1
2023-07-10move has_repr to layout, handle repr(transparent) properlyErik Desjardins-9/+1
2023-07-10i686-windows: pass arguments with requested alignment > 4 indirectlyErik Desjardins-0/+9
2023-07-07Rollup merge of #113467 - nbdd0121:unwind, r=compiler-errorsMichael Goulet-11/+5
Fix comment of `fn_can_unwind` Reopen of #113213
2023-07-05Move `TyCtxt::mk_x` to `Ty::new_x` where applicableBoxy-20/+21
2023-07-04Replace `mk_const` with `Const::new_x` methodsBoxy-5/+3
2023-07-01Put `FnAbiError` behind reference to shrink resultNilstrieb-14/+6
The `FnAbi` is just a pointer, so the error type should not be bigger.
2023-07-01Put `LayoutError` behind reference to shrink resultNilstrieb-11/+21
`LayoutError` is 24 bytes, which is bigger than the `Ok` types, so let's shrink that.
2023-06-30Fix comment of `fn_can_unwind`Gary Guo-11/+5
2023-06-19Don't ICE on unnormalized struct tail in layout computationMichael Goulet-1/+7
2023-06-01Use translatable diagnostics in `rustc_const_eval`Deadbeef-42/+33
2023-05-18Rollup merge of #111633 - nnethercote:avoid-ref-format, r=WaffleLapkinDylan DPC-1/+1
Avoid `&format("...")` calls in error message code. Some error message cleanups. Best reviewed one commit at a time. r? `@davidtwco`
2023-05-17Finish move of query.rsJohn Kåre Alsaker-4/+5
2023-05-16Avoid `&format("...")` calls in error message code.Nicholas Nethercote-1/+1
Error message all end up passing into a function as an `impl Into<{D,Subd}iagnosticMessage>`. If an error message is creatd as `&format("...")` that means we allocate a string (in the `format!` call), then take a reference, and then clone (allocating again) the reference to produce the `{D,Subd}iagnosticMessage`, which is silly. This commit removes the leading `&` from a lot of these cases. This means the original `String` is moved into the `{D,Subd}iagnosticMessage`, avoiding the double allocations. This requires changing some function argument types from `&str` to `String` (when all arguments are `String`) or `impl Into<{D,Subd}iagnosticMessage>` (when some arguments are `String` and some are `&str`).
2023-05-04IAT: Introduce AliasKind::InherentLeón Orell Valerian Liehr-1/+1
2023-05-02Avoid ICEing miri on layout query cyclesOli Scherer-0/+5
2023-04-24Split `{Idx, IndexVec, IndexSlice}` into their own modulesMaybe Waffle-1/+1
2023-04-17Spelling - compilerJosh Soref-3/+3
* account * achieved * advising * always * ambiguous * analysis * annotations * appropriate * build * candidates * cascading * category * character * clarification * compound * conceptually * constituent * consts * convenience * corresponds * debruijn * debug * debugable * debuggable * deterministic * discriminant * display * documentation * doesn't * ellipsis * erroneous * evaluability * evaluate * evaluation * explicitly * fallible * fulfill * getting * has * highlighting * illustrative * imported * incompatible * infringing * initialized * into * intrinsic * introduced * javascript * liveness * metadata * monomorphization * nonexistent * nontrivial * obligation * obligations * offset * opaque * opportunities * opt-in * outlive * overlapping * paragraph * parentheses * poisson * precisely * predecessors * predicates * preexisting * propagated * really * reentrant * referent * responsibility * rustonomicon * shortcircuit * simplifiable * simplifications * specify * stabilized * structurally * suggestibility * translatable * transmuting * two * unclosed * uninhabited * visibility * volatile * workaround Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-12Make rust-intrinsic ABI unwindableGary Guo-2/+3
Stick `#[rustc_nounwind]` to all except `const_eval_select` to undo the change for all other intrinsics.
2023-04-08Auto merge of #106281 - JulianKnodt:transmute_const_generics, r=b-naberbors-0/+95
Add ability to transmute (somewhat) with generic consts in arrays Previously if the expression contained generic consts and did not have a directly equivalent type, transmuting the type in this way was forbidden, despite the two sizes being identical. Instead, we should be able to lazily tell if the two consts are identical, and if so allow them to be transmuted. This is done by normalizing the forms of expressions into sorted order of multiplied terms, which is not generic over all expressions, but should handle most cases. This allows for some _basic_ transmutations between types that are equivalent in size without requiring additional stack space at runtime. I only see one other location at which `SizeSkeleton` is being used, and it checks for equality so this shouldn't affect anywhere else that I can tell. See [this Stackoverflow post](https://stackoverflow.com/questions/73085012/transmute-nested-const-generic-array-rust) for what was previously necessary to convert between types. This PR makes converting nested `T -> [T; 1]` transmutes possible, and `[uB*2; N] -> [uB; N * 2]` possible as well. I'm not sure whether this is something that would be wanted, and if it is it definitely should not be insta-stable, so I'd add a feature gate.
2023-04-07Add feature gatekadmin-7/+9
2023-04-04Use `FieldIdx` in `FieldsShape`Scott McMurray-1/+2
Finally got to the main motivating example from the MCP :)
2023-04-04Add ability to transmute with generic constskadmin-0/+93
Previously if the expression contained generic consts and did not have a directly equivalent type, transmuting the type in this way was forbidden, despite the two sizes being identical. Instead, we should be able to lazily tell if the two consts are identical, and if so allow them to be transmuted.
2023-03-30Update `ty::VariantDef` to use `IndexVec<FieldIdx, FieldDef>`Scott McMurray-3/+3
And while doing the updates for that, also uses `FieldIdx` in `ProjectionKind::Field` and `TypeckResults::field_indices`. There's more places that could use it (like `rustc_const_eval` and `LayoutS`), but I tried to keep this PR from exploding to *even more* places. Part 2/? of https://github.com/rust-lang/compiler-team/issues/606
2023-03-13Layout of `&dyn Trait<[type error]>` is still wideMichael Goulet-1/+5
2023-03-04Rollup merge of #108669 - Nilstrieb:query-my-uninitness, r=compiler-errorsDylan DPC-1/+6
Allow checking whether a type allows being uninitialized This is useful for clippy ([rust-lang/clippy#10407](https://github.com/rust-lang/rust-clippy/issues/10407)) and for the future `MaybeUninit::assume_init` panics (#100423).
2023-03-03Match end user facing unmatched backticks in compiler/est31-1/+1
2023-03-02Allow checking whether a type allows being uninitializedNilstrieb-1/+6
This is useful for clippy and for the future `MaybeUninit::assume_init` panics.
2023-02-27Unify all validity check intrinsicsNilstrieb-4/+18
Also merges the inhabitedness check into the query to further unify the code paths.
2023-02-27Rollup merge of #108364 - Nilstrieb:validity-checks-refactor, r=compiler-errorsMatthias Krüger-0/+17
Unify validity checks into a single query Previously, there were two queries to check whether a type allows the 0x01 or zeroed bitpattern. I am planning on adding a further initness to check in #100423, truly uninit for MaybeUninit, which would make this three queries. This seems overkill for such a small feature, so this PR unifies them into one. I am not entirely happy with the naming and key type and open for improvements. r? oli-obk
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 13:22:34 +0000