RFR: 7903602: Simplify handling of structs/unions [v2]

[Maurizio Cimadamore]

On Fri, 8 Dec 2023 21:53:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR simplifies how declarations and layouts for C structs/unions are created, by splitting the monolithic `RecordLayoutComputer` into two passes:
>> 
>> 1. As part of parsing (in `TreeMaker`) a scoped declaration is created for a struct, which contains all the relevant fields. This declaration is annotated with a bunch of attributes which reify some of the properties of the underlying clang cursors/types (such as sizes, alignments and offsets).
>> 2. We now have a new static method in `Declaration`, namely `Declaration::layoutFor` which allows clients to obtain the layout for a given declaration. For most declaration, this method will get the type and then call `Type::layoutFor`. But for scoped declarations we will compute a new struct/union layout.
>> 3. The already computed layouts are attached to the scoped declaration using an attribute, so that we avoid computing things multiple times.
>> 
>> I actually started off with a declaration visitor which attached layouts to all scoped declarations, but then reverted to a more lazy approach like the one described in (2) because this approach is more amenable for tests dynamically querying layouts of parsed declarations (whereas if layouts depended on a certain visitor being run after parsing, all such tests could not be supported).
>> 
>> Note that the logic which computes a struct/union layout is designed so that it always yields the same answer. That is, even if a client asks the layout for a nested anon struct first, the layout is computed correctly. This is possible because I've removed a lot of stateful logic from the computation, namely:
>> 
>> * the name of anonymous nested declaration is uniquely derived from the declaration position
>> * the starting offset used for layout computation is derived from the offset of the first member of the scoped declaration (if we're seeing an anonymous struct, otherwise the starting offset is just zero)
>> 
>> An interesting consequence of this PR is that now the Declaration/Type API become layout-agnostic: while it's possible to compute a layout/function descriptor from a declaration or type, the declaration/type IRs do not embed any layout information. This change is also evident in the treatment for primitive types, which no longer have a pre-determined associated layout. That is, jextract declaration are now pure wrappers around clang cursors, and nothing more. Of course given the information in a declaration we can derive a layout, but that's an orthogonal operation: a...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

As discussed offline, I will follow up on this patch with a change to make the size/alignment/offset information part of the jextract Type/Declaration APIs, rather than having them be as optional attributes, which, I think, is closer to the spirit of what the declaration API wants to achieve.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/154#issuecomment-1847910054