RFR: 7903666: Jextract should report issues with missing dependencies

Jorn Vernee jvernee at openjdk.org
Fri Feb 16 16:01:09 UTC 2024


On Fri, 16 Feb 2024 15:39:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When custom include filters are specified on the command line, it is possible for jextract to generate non-sensical code (now even more so than in the past). Possible issues:
>> 
>> * a function descriptor refers to a non-existent struct/union
>> * a struct/union typedef refers to a non-existent struct/union
>> * a struct/union field refers to a non-existent struct/union
>> * a global variable refers to a non-existent struct/union
>> 
>> In such cases, jextract should terminate (and report the problem to the user), rather than generating buggy code.
>> 
>> The fix is relatively simple, and amounts at checking whether a declaration depends on a skipped struct in `IncludeHelper`. That said, when we detect an issue, we should stop jextract. So we need some way to notify jextract that some error occurred, and stop.
>> 
>> I initially had a hacky approach with some mutable field in `IncludeFilter`, but I've decided to implement a minimal Logger class, and make _all_ error/warnings go through the Logger. This way we can easily check how many errors occurred, and stop jextract if needed. Of course, this led to several changes, as I realized that we were being inconsistent on our usage of the property file. I now made sure that all messages use some key in the property file (e.g. no lone strings). This might be important if jextract message will ever be translated to languages other than English.
>
> src/main/java/org/openjdk/jextract/impl/OutputFactory.java line 67:
> 
>> 65: 
>> 66:     private void generateDecl(Declaration tree) {
>> 67:         tree.accept(this, null);
> 
> the try/catch seemed suspicious, and was also printing on std err, so I dropped that (after all, if some unexpected exception happens, we want to know?)

I suppose this was added when jextract was less stable, or lacked filtering support. So, if we got an exception while generating one of the trees, jextract would still output _something_

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

PR Review Comment: https://git.openjdk.org/jextract/pull/214#discussion_r1492666079


More information about the jextract-dev mailing list