jextract JDK19 Windows enum handling

[Maurizio Cimadamore]

After thinking some more, I don't think there's a sane way to keep both 
--include-enums and having a more fine-grained enum constant option. The 
mechanism we have now is very simple, where jextract just dumps whatever 
it finds on a set of disjoint include-xyz flags. We could in principle 
tweak the impl so that --include-enum included "all constants" whereas 
if that flag is missing, it falls back to use --include-constant - but 
then what would jextract dump?

Since the boundary between enums and defined constants is so blurry in 
C, I'm inclined to just revert.

Maurizio

On 06/06/2022 10:37, Duncan Gittins wrote:
> I hope it would be possible to deal with both ways for (2). The 
> --include-enum option works very well when there are a few values per 
> enum like SLGP_FLAGS (even though I only need SLGP_SHORTPATH), but 
> there are some enums which contain many more definitions and the view 
> of the generated code and IDE code completion) looks very bloated when 
> it contains so many unreferenced definitions.
>
> Due to the bug (1) my compiled jextract jar is 45% bigger than under 
> JDK18 jextract - that is quite a jump if my Java code was only 
> dependent on one item from each of those enums that are incorrectly added.
>
> Kind regards
>
> Duncan
>
> On Sun, 5 Jun 2022 at 22:35, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Hi Dunan,
>     (1) looks like a bug. I'll need to think about (2). I see where
>     you are
>     coming from. At the same time it's tricky, because we filter out most
>     stuff by "name" (e.g. struct name, function name, etc.) - and we
>     do not
>     provide functionality to filter out at _deeper_ levels of nesting.
>     The
>     fact that constants worked the way they did was more of an happy
>     accident rather than the result of a conscious decision.
>
>     While we could go back to previous behavior, I feel like, in some
>     cases
>     at least, a developer might want to include an entire enum, w/o
>     really
>     having to enumerate all the constants.
>
>     Maurizio
>
>     On 05/06/2022 13:47, Duncan Gittins wrote:
>     > I'm a bit behind with all latest Panama messages so apologies if
>     this
>     > repeats existing issues. I've been testing out latest jextract
>     from master
>     > branch, along with jdk19 - both with non-incubator foreign
>     package names.
>     >
>     > There are some unexpected enum values in extractions, perhaps
>     related to
>     > https://bugs.openjdk.java.net/browse/CODETOOLS-7903198
>     >
>     > Test with header file "Shell32.h" which contains "#include
>     <shlobj_core.h>"
>     >
>     > 1) With latest JDK19 branch I see an enum that I don't use, and this
>     > appears every time regardless of "--include--xxx" flags:
>     >
>     >      jextract --source -lshell32 -t win.shell --output
>     shell19.src Shell32.h
>     > --include-enum THIS_DOES_NOT_EXIST
>     >      => Shell32_h contains 100+ values of "WELL_KNOWN_SID_TYPE"
>     >
>     > [ BTW: It would be nice if jextract had a mode (eg
>     "--show-warnings") which
>     > reported "No such enum: THIS_DOES_NOT_EXIST".]
>     >
>     > 2) Is there a way to extract one enum value SLGP_SHORTPATH with
>     JDK19
>     > jextract?
>     >
>     > In previous JDK18 jextract release I could extract a single enum
>     value
>     > SLGP_SHORTPATH (with "--include-macro" which was changed in
>     > CODETOOLS-7903198)
>     >
>     >       jextract --source -lshell32 -t win.shell --output shell18.src
>     > Shell32.h --include-macro SLGP_SHORTPATH
>     > =>  class Shell32_h  { // omitted lines with Constants$root....
>     >          public static int SLGP_SHORTPATH() { return (int)1L;  }
>     >      }
>     >
>     > Adding "--include-enum SLGP_FLAGS" will introduce new
>     definitions including
>     > SLGP_SHORTPATH (and WELL_KNOWN_SID_TYPE), but it would be nicer
>     to have
>     > just a single definition for the value "SLGP_SHORTPATH".
>     >
>     > Kind regards
>     >
>     > Duncan
>