On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda <jlah...@openjdk.org> wrote:
>> This PR proposes to improve handling of javac's `Flags` in two ways: >> - for each flag, there's now an informational annotation specifying what is >> the target Symbol type. Only targets right now are `TypeSymbol`s, >> `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, >> we could split those to module/package/class/type variable, but it does not >> seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which >> is for `JCBlock`. >> - the manually handled `Flags.Flag` enum is replaced with autogenerated >> `FlagsEnum` >> >> This is inspired by: >> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662 >> >> There may be some better to handle `Flags` eventually, but this hopefully >> improves the current situation at least somewhat, by providing more formal >> way to say the flags' target, and restricting the need to read comments and >> search for free flags. >> >> As a side-effect of this annotation, the >> `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which >> flags are free, for each Symbol type. >> >> (I will remove the `build` label for now, until discussion on javac level is >> done, and will re-add it if we decide the goal to autogenerate the FlagsEnum >> makes sense.) > > Jan Lahoda has updated the pull request incrementally with three additional > commits since the last revision: > > - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885 > - Using EnumMap, as suggested. > - Removing unnecessary delimited, as suggested. Looks good. This should have minimal impact to javac performance. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3107758710
