Fix #5008: forbid any class extending enums

[Blaisorblade]

Forbid any class from extending enums. However, keep allowing to extend Enum by hand (per current testcase). Thanks to @allanrenucci for the suggesting how.

Building on top of #5028, and alternative to it.

I'm not sure that's a good idea — there's a testcase from 2017 about this (from d3b2c37, 0ee3281), but it doesn't seem in the spirit of the current restricted enums.

/cc @hrhino.

[allanrenucci]

I think we don't need a special error message for case class anymore

[allanrenucci]

Why is this test removed?

[Blaisorblade]

It appears to be entirely about the feature we’re removing, which is why I asked about it.

[allanrenucci]

Comment irelevant

[Blaisorblade]

No, the messages should be evolved together, so it’s relevant for maintainers. I can make that clearer tho.

[allanrenucci]

Why not simply: ${cls.name} inherits from enum ${firstParent.name}, ...?

[Blaisorblade]

Because that doesn’t say that inheriting from an enum is a problem. We explain that even for case classes, as the “irrelevant” comment points out.

[allanrenucci]

I didn't mean to remove the part after the comma, just rephrase the first part:

"${cls.name} inherits from enum ${firstParent.name}, but inheriting from enums is prohibited"

I find it weird to talk about ancestor when it really is the first parent. Ideally enum should be treated as effectively final and we should report errors similarly to final inheritance rather than case to case inheritance. Ideally something like:

enum Foo { case F }
class Bar extends Foo
class Bat extends Bar

shoud report similar errors as:

final class Foo
class Bar extends Foo // error: class Bar cannot extend final class Foo
class Bat extends Bar // no error here

[Blaisorblade]

Memo to self: using the flag would not be transitive, so it would also avoid this double reporting.

[allanrenucci]

And the two commits should be squashed since the second commit pretty much reverts the first one

[allanrenucci]

I'm not sure that's a good idea — there's a testcase from 2017 about this (from d3b2c37, 0ee3281), but it doesn't seem in the spirit of the current restricted enums.

I think we can differentiate between extending enums and extending the trait Enum. The former would be an error but the latter would be OK (I believe it is similar in Java). Testing if the first parent has the Enum flag instead of doing a subclass check (i.e. derivesFrom(defn.EnumClass)) should do the trick

[odersky]

@Blaisorblade This has been inactive for a month. Let's finish it now.

Comments addressed