| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
field in `LayoutData`.
Also update comments that refered to BackendRepr::Uninhabited.
|
|
By moving this stability check into AST lowering, we effectively make
it impossible to accidentally miss, as it must happen to generate HIR.
Also, we put the ABI-stability code next to code that actually uses it!
This allows code that wants to reason about backend ABI implementations
to stop worrying about high-level concerns like syntax stability,
while still leaving it as the authority on what ABIs actually exist.
It also makes it easy to refactor things to have more consistent errors.
For now, we only apply this to generalize the existing messages a bit.
|
|
General housekeeping:
- Use less reexports from its rustc_target era
- Unify some imports as a result
- Split the Reg(ister) types into their own files
Generally moving stuff around because it makes the crate more consistent.
|
|
|
|
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.
|
|
|
|
This finally unites TyAndLayout, Layout, and LayoutS into the same crate,
as one might imagine they would be placed. No functional changes.
|
