remove dollar ordinal from Enum

[bishabosha]

$ordinal only existed so that ordinal could be later added if the implementation did not extend java.lang.Enum, however we can check at desugaring the parents of the enum class and avoid defining ordinal in a concrete implementation of jl.Enum,

secondly, we can also remove $ordinal and toString override in concrete cases extending jl.Enum to avoid unnecessary field creation

[bishabosha]

Here is a sketch for a cleaner implementation

enum Tag[T] extends java.lang.Enum[Tag[_]]:
  case IntTag extends Tag[Int]

previously, IntTag would desugar to:

final case <enum> val IntTag: Tag[Int] =
  new Tag[Int] with runtime.EnumValue {
    override def toString: String = "IntTag"
    override def $ordinal: Int = 0
  }

and after completeJavaEnums become:

final case <enum> val IntTag: Tag[Int] =
  new Tag[Int]("IntTag", 0) with runtime.EnumValue {
    override def toString: String = "IntTag"
    override def $ordinal: Int = 0
  }

instead we can do:

@annotation.internal.ValueEnumCase("IntTag", 0)
final case <enum> val IntTag: Tag[Int] =
  new Tag[Int] with runtime.EnumValue {}

which after completeJavaEnums become:

@annotation.internal.ValueEnumCase("IntTag", 0)
final case <enum> val IntTag: Tag[Int] =
  new Tag[Int]("IntTag", 0) with runtime.EnumValue {}

[smarter]

That seems like quite a lot of indirection, could completeJavaEnums compute the ordinal value itself?

[bishabosha]

@smarter thanks for the tip, I now use a reverse lookup of the enum class children

[bishabosha]

There doesn't seem to be an optimal way of building the map of case -> ordinal that ignores simple enum cases, unless it was prepared in an earlier stage

[smarter]

There doesn't seem to be an optimal way of building the map of case -> ordinal that ignores simple enum cases

Is the issue that we can have a mix of simple and non-simple cases? If so, do we have testcases that check that enums with mixes like this are correctly generated (ordinal behaves as expected on all values, etc).

[bishabosha]

Is the issue that we can have a mix of simple and non-simple cases?

That is correct, if there was no way to mix them then the branch for companions could be removed, and I'll add a test with mixing cases