RFR: 7903485 Windows.h fails to extract on jextract/panama

[Maurizio Cimadamore]

On Wed, 7 Jun 2023 14:01:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch fixes a number of issues I discovered while trying to extract Windows.h on a recent jextract:
>> 
>> * the size of `long double` layout is wrong. This means that if a struct with a field of that type is declared, StructLayoutComputer will fail (as it will see a size != expected size reported by clang)
>> * There are cases where, also for unsupported layouts, we end up creating function descriptors with things containing padding. This is caused by the fact that the check for unsupported layouts in functions is performed *after* the creation of the function descriptor.
>> * Sometimes libclang reports field cursors in an out-of-order fashion. I have not been able to pinpoint the exact cause, as all my attempts to create a reduced test case failed. When this behavior occurs, jextract ends up generating extra fields and padding. I believe this behavior has always been there, but now brought to the fore by the new eager checks.
>> * A change in behavior of recent libclang causes `cursor.spelling()` to return non-empty strings (see https://github.com/llvm/llvm-project/issues/58429)
>> * A quality of life fix, to generate "sensible" warnings when variadic callbacks are found
>
> src/main/java/org/openjdk/jextract/impl/StructLayoutComputer.java line 91:
> 
>> 89:         if (offset > expectedOffset) {
>> 90:             // out-of-order field, skip
>> 91:             return;
> 
> So, I think as a result of returning here, we will essentially just emit padding instead of the out of order field, right?
> 
> I think it would be nice to log a message as well to let the user know that something went wrong, and the resulting layout might not be usable (similar to how we do that for unsupported layouts)

What happens here is that, typically, we already have generated a padding _before_ (e.g. because we jumped into a struct, and saw that first offset is e.g. 42). So we later go back and see offset 0, so we try to emit something for which we already have emitted padding. The layout will be usable (e.g it has right size and alignmment), but some fields will be skipped.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/122#discussion_r1226515168