| Age | Commit message (Collapse) | Author | Lines |
|---|
|
We lost the following comment during refactorings:
The current code for niche-filling relies on variant indices instead of actual discriminants, so enums with explicit discriminants (RFC 2363) would misbehave.
|
|
default data address space
|
|
|
|
|
|
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
|
|
|
|
implement or-patterns for pattern types
These are necessary to represent `NonZeroI32`, as the range for that is `..0 | 1..`. The `rustc_scalar_layout_range_*` attributes avoided this by just implementing wraparound and having a single `1..=-1` range effectively. See https://rust-lang.zulipchat.com/#narrow/channel/481660-t-lang.2Fpattern-types/topic/.60or.20pattern.60.20representation.20in.20type.20system/with/504217694 for some background discussion
cc https://github.com/rust-lang/rust/issues/123646
r? `@BoxyUwU`
|
|
async_drop_in_place::{closure}, scoped async drop added.
|
|
|
|
|
|
|
|
|
|
|
|
Also properly attaches spans on layouts of non-promoted coroutine
locals, which slightly improves the error messages for some coroutine tests.
|
|
|
|
...either as:
- methods on LayoutCalculator, for faillible operations;
- constructors on LayoutData, for infaillible ones.
|
|
|
|
|
|
|
|
These aren't supported anymore, and are already rejected in type checking.
|
|
|
|
r=bjorn3,RalfJung
compiler: untangle SIMD alignment assumptions
There were a number of puzzling assumptions being made about SIMD types and their layout that I have corrected in this diff. These are mostly no-op edits in actual fact, but they do subtly alter a pair of checks in our invariant-checking and union layout computation that rested on those peculiar assumptions. Those unfortunately stand in the way of any further actual fixes. I submit this for review, even though it's not clearly motivated without its followups, because it should still be possible to independently conclude whether this is correct.
|
|
|
|
Introduce a pair of functions that actually describe what they do,
because it wasn't clear the alignment is sometimes a forgery.
|
|
No functional changes.
|
|
field in `LayoutData`.
Also update comments that refered to BackendRepr::Uninhabited.
|
|
- change function parameter order to `cx, ty, ...` to match the other
functions in this file
- use `ct` identifier for `ty::Const` to match the majority of the
compiler codebase
- remove useless return
- bring match arms in a more natural order
|
|
Remove the `repr` parameter from the wrappers around `calc.univariant`,
because it's always defaulted. Only ADTs can have a repr and those call
`calc.layout_of_struct_or_enum` and not `calc.univariant`.
|
|
- we normalize before calling `layout_of_uncached`, so we don't need to
normalize again later
- we check for type/const errors at the top of `layout_of_uncached`, so
we don't need to check again later
|
|
`ty::Placeholder` is used by the trait solver and computing its layout
was necessary, because the `PointerLike` trait used to be automatically
implemented for all types with pointer-like layout.
Nowadays, `PointerLike` requires user-written impls and the trait solver
no longer computes any layouts, so this can be removed.
Unevaluated constants that aren't generic should have caused a const eval
error earlier during normalization.
|
|
with rust-analyzer
|
|
|
|
The wording unsafe pointer is less common and not mentioned in a lot of
places, instead this is usually called a "raw pointer". For the sake of
uniformity, we rename this method.
This came up during the review of
https://github.com/rust-lang/rust/pull/134424.
|
|
|
|
Co-authored-by: FedericoBruzzone <federico.bruzzone.i@gmail.com>
|
|
- `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
|
|
spurious errors
|
|
This should make it clearer that this bitset is dense, with the
advantages and disadvantages that it entails.
|
|
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
|
|
|
|
|
|
|
|
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
|
|
|
|
|
|
|
|
|
|
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
|
|
|
|
The initial naming of "Abi" was an awful mistake, conveying wrong ideas
about how psABIs worked and even more about what the enum meant.
It was only meant to represent the way the value would be described to
a codegen backend as it was lowered to that intermediate representation.
It was never meant to mean anything about the actual psABI handling!
The conflation is because LLVM typically will associate a certain form
with a certain ABI, but even that does not hold when the special cases
that actually exist arise, plus the IR annotations that modify the ABI.
Reframe `rustc_abi::Abi` as the `BackendRepr` of the type, and rename
`BackendRepr::Aggregate` as `BackendRepr::Memory`. Unfortunately, due to
the persistent misunderstandings, this too is now incorrect:
- Scattered ABI-relevant code is entangled with BackendRepr
- We do not always pre-compute a correct BackendRepr that reflects how
we "actually" want this value to be handled, so we leave the backend
interface to also inject various special-cases here
- In some cases `BackendRepr::Memory` is a "real" aggregate, but in
others it is in fact using memory, and in some cases it is a scalar!
Our rustc-to-backend lowering code handles this sort of thing right now.
That will eventually be addressed by lifting duplicated lowering code
to either rustc_codegen_ssa or rustc_target as appropriate.
|
