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

[Maurizio Cimadamore]

On Thu, 1 Jun 2023 15:15:56 GMT, Maurizio Cimadamore <mcimadamore 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

Note - I did not add new tests. For some of the stuff I could reproduce (e.g. failure when creating function descriptor, or issues with `long double` size) we already have tests (see LibUnsupportedTest), and I suspect these tests fail w/o this patch (but I have not tried). Similarly, I believe that some tests will fail when running against a recent version of libclang, due to the cursor.spelling() changes.

There is no new test for the out of order issue with record fields (as I have no reproducer, unfortunately).

src/main/java/org/openjdk/jextract/impl/OutputFactory.java line 225:

> 223:         //generate functional interface
> 224:         if (func.varargs() && !func.argumentTypes().isEmpty()) {
> 225:             warn("varargs in callbacks is not supported: " + CDeclarationPrinter.declaration(func, javaName));

This is a quality of life fix - on Windows, a very very big message is reported as we print out the function descriptor of the corresponding C function. By turning that into a C type (using same logic we use for javadoc generation) the warning messages is more amenable.

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

PR Comment: https://git.openjdk.org/jextract/pull/122#issuecomment-1572312222
PR Review Comment: https://git.openjdk.org/jextract/pull/122#discussion_r1213343668