Make niches part of layout and expand call ABI #153
Conversation
|
So I've added some clarifications to the ABI and the examples. |
|
@gnzlbg this PR has conflicts now. Can you resolve that, and fix the nit? Then I am going to merge. This has sat long enough with an "approved" seal and nobody complaining. |
|
Kind of related, we can do the same in the compiler too: rust-lang/rust#62692 |
Co-Authored-By: Ralf Jung <[email protected]>
gnzlbg
force-pushed
the
layout2
branch
2 times, most recently
from
85ecb46 to
9546c7a
Compare
Co-Authored-By: Ralf Jung <[email protected]>
|
Done. |
|
Hm okay I am having second thoughts about merging this without hearing from anyone else in the WG. After all this (re)defines a key term. @rust-lang/wg-unsafe-code-guidelines please share your thoughts. :) Also, do we need to update any of the other existing text that talks about "layout"? I am thinking in particular of statements of the form "A and B have the same layout". |
|
Saying incorrect things until the update has been carried out seems bad, though. |
|
So I went through all uses of "layout" and updated everything except for struct and enum documents. I don't think anything "incorrect" in these two documents, but they mix the term "layout" with "memory layout" quite freely, and they also use the term C-compatible layout, but AFAICT C has no notion of niches, so I'm unsure what to do there. |
|
Thanks! That looks great. "C-compatible layout" might be worth defining here? But leaving that for later is also okay. However, I would like to see an ack of some other WG member before merging. |
I think we need a different term for "size+alignment" (e.g. "memory layout" ?), "size+alignment+call AB" (e.g. "abi" ?), and what Rust uses for layout optimizations (size+alignment+abi+niche, e.g., just "layout"). Otherwise being explicit about each term gets repetitive and error prone, and it is hard to refactor as we iterate on "layout"'s definition. |
I like "shape", but I am not sure what exactly that should include. |
|
How about
|
|
I'd maybe put call layout at the end of the list. There's many data transforms you might care to do that worry about size/align/niche but don't care about call |
There was a problem hiding this comment.
The conclusion in the meeting was that we should avoid the term "layout" in the reference, and instead define in the glossary which components a layout can have, and then always spell that out explicitly, probably with an abbreviation like "they have the same SAN-layout" [size, alignment, niche].
|
Also see #122 (comment), where we are going back to the drawing board and considering calling these sub-aspects of "layout" "ABIs". So there would be a bunch of ABIs (call ABI, memory ABI, maybe something like "nesting ABI" that includes a niche and means things are the same even when nested in other types?"), and all of that together would be called "layout". Or so. |
RalfJung
added
the
S-blocked
| ```rust,ignore | ||
| enum Abi { | ||
| Uninhabited, | ||
| Scalar(Scalar), |
There was a problem hiding this comment.
That's intentional. ScalarPair is an implementation detail useful for some optimizations that we don't want to guarantee it exists - right @eddyb ?
There was a problem hiding this comment.
Yeah, it's just an aggregate that we pass around as two scalars only in Rust ABIs and within functions.
Yes. Just to confirm, the temporary plan until we have a better solution is to continue to call this "Layout", but writing down for each case what exactly do we guarantee (SAN-layout), right ? |
|
That was the plan before "X ABI" got proposed and gained some traction. Not sure if it still is the plan. |
|
I think it would be at least helpful to know what do we precisely guarantee where for coming up with the "X" in the "X ABI" plan. |
|
Sure @Lokathor go ahead, this will need many changes anyways. |
|
There was no activity here for quite a while so I am going to close this PR; looks like more discussion in #122 is needed. |
Closes #122
cc @eddyb
(Once the other PRs are merged I'll update the links here).