closed ambiguous enum defaults to first overload

[metagn]

In the case where a closed enum field symchoice cannot collapse to a type, assume it has the type of the first overload in the symchoice. From what I understand this is also the closest overload in scope.

Unfortunately this also applies to enum types in the same scope, as disallowing this would require iterating over the overloads again. But this was not possible without overloadableEnums, and the type system should point out issues.

This allows some code that didn't use overloadableEnums to work. Specifically, this should make code that broke with #20298, namely the regression in the comments #20298 (comment) and later reported on the forum https://forum.nim-lang.org/t/9474#62224 work.

This gives a warning that can be turned into an error with --warningAsError:AmbiguousEnum.

[Araq]

That's a great solution as it mimics how proc overloading works, roughly.

[metagn]

Added warning for when this happens, can remove/turn to a hint if needed.

[Menduist]

Thanks a lot @metagn for going through with this :)

If this is the same behavior as proc, but proc do it silently, maybe a hint / nothing makes more sense?

[metagn]

This is the difference with procs:

type Foo = enum abc
type Bar = enum abc

assert abc is Bar

# a.nim
type Foo* = enum abc

# b.nim
type Bar* = enum abc

# c.nim
import a, b

assert abc is Bar

I can't think of an efficient way to deal with this, so I added the warning in case it's undesired. I think the lowest thing we can do above saying nothing is turning it into a style check hint, or having it completely off by default. But I have no idea what would be best because of how uncommon this is. For now I will turn it to a hint that is off by default.

[Araq]

Needs to be documented in the manual too.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from cfff454

Hint: mm: orc; threads: on; opt: speed; options: -d:release
164381 lines; 16.875s; 665.777MiB peakmem