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

[Maurizio Cimadamore]

On Wed, 3 Feb 2021 10:51:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing merge tags are noted on the review - thanks!
>
> Good experiment! I don't mind too much the fact that we have sets of incompatible flags - but while looking at the new Flags.java I noted several flags that looked *kind-specific* which seem to be defined in the *global* bucket. If (as I suspect) this is no accident, then I guess I'm a bit worried that the proposed patch would land us in a state where _some_ var flags are in the VarSymbolFlags enum, but not _all_ of them.

I'm also worried about where does this leave symbol construction - for instance, in TypeEnter I now see these lines (unchanged in this patch):

params.add(new VarSymbol(
                        GENERATED_MEMBER | PARAMETER | RECORD | (field == lastField && lastIsVarargs ? Flags.VARARGS : 0),
                        field.name, field.sym.type, csym));
 ```

Here, it seems, we are forced to just use a flat flags mask in the constructor - in other words, the new API is only for testing, and there is an asymmetry between construction and testing.

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

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