fix #9873: no longer use scala.Enum as parents of enums

[bishabosha]

fixes #9873

this also adds a new method to deriving.Mirror.Sum to access the enumLabel generically. no longer does this

Also removes the old unused enum helper classes from the non-bootstrapped library

[julienrf]

I don’t have enough expertise to review the implementation but the test enum-mirror-sumOf.scala looks good to me!

[sjrd]

This looks good to me, but it would be good to have confirmation from someone from the core dotty team on whether the new untpd tree is the right way to go.

[odersky]

I think we should try to simplify this and reduce the scope. Let's discuss and possibly implement enumLabels separately. For dropping scala.Enum, the approach looks good, but I think it can be simplified.

[bishabosha]

@odersky I have revisited the implementation so that the only special case is to add ordinal to the cases invalidated in invalidateIfClashingSynthetic, and there is no change to either error messages, untpd, or deriving.Mirror.Sum.
The documentation still needs to be updated but I will do that if you are happy with the implementation

[odersky]

Looks all good now, except for the suggested small change in SyntheticMembers.

[bishabosha]

Not really sure why the definitions are disappearing in the sconfig community build

[bishabosha]

so it looks like calling unlink is not enough, it will remove ordinal from the scope, but then it is still visible using findMember on the info of the enum class, and in some situations, like typedSelect when typing the sconfig example, the method is not chosen as it fails reallyExists

Edit: apparently delete does not stop downstream find member either

[odersky]

I think it's better not to remove ordinal. That's very tricky code, and we should use that only when absolutely necessary. As an alternative we could simply change the rhs of ordinal methods for cases of enums that extend java.lang Enum like this:

override def ordinal: Int = super.ordinal

I believe that's much easier to do. We could do this in SyntheticMethods, for instance, or anywhere else before RefChecks.

[bishabosha]

Im not sure I understand, ordinal is a final method so we can't override it

[bishabosha]

@odersky In addition to invalidation I also now do not enter the symbol for ordinal until after typing the parents - but the logic is all localised to the indexExpanded method, but this is far more minimal then running the whole index function after parents (as I did with the EnumGetters magic)

[odersky]

Im not sure I understand, ordinal is a final method so we can't override it

Ah. I did not consider that. Yes, scratch that idea then.

[odersky]

This is quite a heroic effort from @bishabosha's part. It needs some tricky logic in Namer which is already a class that is pushing the complexity budget. But I wonder whether it's worth it. Is it not simpler to just keep the Enum trait? If we are concerned about naming it could be scala.runtime.Enum. That way it won't shadow the Java trait.

[odersky]

I think it could be a valuable for a reflection framework to know that a class or value is an enum case. So having Enum as a marker trait might not be a bad idea after all.

[odersky]

My current preference is to rename scala.Enum to scala.runtime.Enum and otherwise keep things as they are. I believe that's overall simplest.

[odersky]

In fact it could also be scala.reflect.Enum. The runtime package is reserved for classes that should not be mentioned in user code. So scala.runtime.Enum makes sense only if we say the class is an implementation detail. We should discuss this point.

Also, while we are at it, I believe the Enum class should be a super trait.

[bishabosha]

close in favour of #9942