RFR: 8362885: A more formal way to mark javac's Flags that belong to a specific Symbol type only [v2]

[Maurizio Cimadamore]

On Fri, 25 Jul 2025 13:38:38 GMT, Jan Lahoda <jlahoda at 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:
> 
>  - Fixing toString value for flags that have ACC_ overloaded flags.
>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>  - Reflecting review feedback:
>    - when conflict is detected, the generator fails
>    - adding runtime checks
>    - using constants for number of bits

There's a lot to like in this patch. Now flags cannot erroneously overlap, which will give us all javac developers more confidence that we're not stepping into each other toes. Also, by making the mechanism more formally correct, it's easier to see which "holes" we have available (and there's probably quite a lot left).

The only thing I'm unsure of, as pointed out in the review, is the dynamic checks. I believe that, as far as this PR is concerned, this feels like "scope creep". I think it would be cleaner if this PR only concerned about introducing the machinery. Then maybe we can brainstorm separately on what would be the best way to add some of these checks (but I'm skeptical that we can find anything that doesn't feel like a compromise).

For instance, another way to do this could be to do another combo test like the tree test, where we compile all the existing tests, and check the validity of all the flags on all the symbols. That's an offline way to make sure that what we do in javac is "sort of" correct, but one that doesn't leak into the code.

The real fix for this, as we know (and as @archiecobbs commented) is to move away from longs, but that's not what this PR is about.

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

PR Comment: https://git.openjdk.org/jdk/pull/26452#issuecomment-3118166298