RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]

[Maurizio Cimadamore]

On Wed, 3 Feb 2021 13:26:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 167:
>> 
>>> 165:     /** Flag for synthesized default constructors of anonymous classes.
>>> 166:      */
>>> 167:     public static final int ANONCONSTR   = 1<<27;
>> 
>> Question: why this, and other flags that are specific to only one symbol kind have not been translated into the enum? Other examples are `ANONCONSTR_BASED`, `GENERATEDCONSTR`, `COMPACT_RECORD_CONSTRUCTOR`, `THROWS` and probably more.
>
> Some of these (IIRC e.g. GENERATEDCONSTR, ANNONCONSTR) are also set on trees, and read and written as bitmasks, so it is more difficult to separate them to e.g. methods only. A few others could possibly be move with a little more code shuffling.

I see what you mean - as I said, my worry is that, while this patch addresses the paucity of flags in an effective fashion, the resulting code base end up being worse than it was to begin with, as now a client will have to hunt flags in different enums. If the organization was consistent, I'd have no problem with giving each kind of flag its own enum - but given that the organization is more ad-hoc (e.g. driven by which use cases could be morphed into using enums), I'm unsure.

I mean, what's the advantage of the proposed solution vs. organizing the set of long flags in Flags by categories - so that there's no enum, but so that e.g. a variable symbol flag can reuse the same value as some other method symbol flag?

I think it would deliver same saving, w/o the need to change the flag API. Granted, we also not get any protection for when somebody tries to "merge" flags that are not mergeable - but I'm equally not sure as to whether the proposed solution offers a much more principled alternative?

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

PR: https://git.openjdk.java.net/jdk/pull/2316