Avoid brittle flags encoding for Java enums

[som-snytt]

Fixes scala/bug#12800

In the current scheme, an enum should be sealed abstract and have only its elements as "children".

If an enum element has a body, then permittedSubclasses includes the element subclass.

The two tweaks are: don't add those permittedSubclasses as children; set sealed abstract unconditionally (on parsing an enum field, where the enum is already marked sealed).

The symptoms were that patmat would warn about MyEnum$1 (where the anon subclass is a child) or MyEnum forSome not in X,Y,Z (if the enum is not marked abstract).

Second commit expunges the kludge of making enum always abstract just for exhaustivity. Instead, patmat analysis checks for an enum class (isSealedEnum). Class file parser assumes only present flags, except ACC_ENUM is translated to include SEALED for classes. Java parser checks enum members for a deferred member, and sets ABSTRACT accordingly.

[SethTisue]

Second commit expunges the kludge of making enum always abstract just for exhaustivity

Is that kludge something we've had since forever, or something that was added recently?

I guess I'm asking partly out of curiosity and partly because I'm wondering what the risk level is of making a code improvement that isn't strictly necessary to fix bug (right?).

In other words, my "shouldn't this be two PRs" finger is twitching slightly, but my "Seth don't be pedantic" finger is twitching in the direction of the first finger, if the metaphor isn't getting too tortured.

[SethTisue]

To overthink a little further, I guess whether I care about one-PR-or-two depends on whether 2.13.12 ends up being a longer-incubating, optimistically-merge-things type release (as 2.13.11 was), or whether it ends up being an "oh shit we need to roll another one pronto" type release (as 2.13.10 was). And we don't know that yet.

[som-snytt]

@SethTisue I expect @lrytz to weigh in on the second commit, hopefully with a ringing endorsement. Otherwise it can be moved to a separate PR as an internal improvement. (It's an old state of affairs, but I think it turns out to be low-hanging fruit. If I'd been at the recent spree, I would have worn my "low-hanging fruit" t-shirt.)

[lrytz]

LGTM, both commits, just the isSealedEnum extension method seems a bit of an overkill.

[lrytz]

Here I don't follow, when is isClass true, when is it false?

[som-snytt]

The enum member fields get the flag. (I believe I did not imagine that.)

[som-snytt]

Updated with two suggestions. (Edit: and rebased)

In the beginning, I expected to be calling isBlahBlah all over the place, but I see it wound up as just a tweak to two expressions.

That is not in proportion to the degree of suffering required.

Also adjusted indentation on the flag translation, so that it fits in my default terminal.

Reluctantly renamed variable abbie to hasAbstractFlag (change not explicitly requested).

I did not squash the two commits, but I did squash the two amendments. Dangerous to do before finishing first coffee! After deleting the package object, it tried to leak back into the second commit. ("How does git actually work again?")

[lrytz]

Reluctantly renamed variable abbie to hasAbstractFlag (change not explicitly requested).

I like sentimental codebases