implement RFCs/294 ; disallow enum <=> enum conversion

[timotheecour]

• fix disallow enum to enum conversion (require passing through ord) RFCs#294
• allow -d:nimLegacyConvEnumEnum

CI failures caused by this:

only those 2:

• nimgame2
  /Users/runner/work/Nim/Nim/pkgstemp/nimgame2/nimgame2/texturegraphic.nim(241, 41) Error: type mismatch: got but expected 'RendererFlip = enum'
• nimquery
  /Users/runner/work/Nim/Nim/pkgstemp/nimquery/nimquery.nim(915, 68) Error: type mismatch: got but expected 'Combinator = enum'

these packages can be fixed upstream, or testament can add logic to pass flags (eg -d:nimLegacyConvEnumEnum or everytime such kind of issue shows up) to tests that need custom flags; this can be done by overriding XDG_CONFIG_HOME for those tests, pointing to a custom config.nims, so that these flags apply recursively through nim invocations via exec. (EDIT: see nim-lang/RFCs#336)

future work

• reenable nimquery in important_packages after fix for RFC/294 ; disallow enum <=> enum conversion GULPF/nimquery#10 gets merged => re-enable nimquery #17936

[cooldome]

cast from one enum to another should work, please test. IMO, cast should work even if enums have different byte size.

Should changelog recommend cast instead of ord?

[timotheecour]

cast from one enum to another should work, please test. IMO, cast should work even if enums have different byte size.

done

Should changelog recommend cast instead of ord?

no, cast is overkill in this use case, and won't help catch bugs eg:
cast[Foo](bar) would happily cast any type to any type. ord should have 0 overhead.

[timotheecour]

PTAL

[timotheecour]

@Araq PTAL (fixed bitrot)

[timotheecour]

ping @Araq I had to rebase again to fix bitrot

[alaviss]

Can we have a migration error message for this? This will be extremely confusing for anyone not tracking devel and not having their code in important_packages (I have to debug one such codebase recently).

I'm a bit worried how we keep on introducing tiny breaking changes in the language spec between versions.

[timotheecour]

that's what -d:nimLegacyConvEnumEnum + the changelog section Changes affecting backward compatibility is for, those changes are made for a reason.

The changelog clearly mentions this change. In any case, I've just sent out #17928 for this case, but in other cases, it may not always be practical to do this (see that section in the changelog). Users who upgrade should read that section.

[Clyybber]

I'm not sure anymore wether this change is a good idea, the user is already explicit when writing foo.Bar, having to add .ord in there is unneccessary syntax salt.
I was originally positive about this change because two enums might not have any meaningful relation and this would make conversions between them more explicit, but thinking more about it I don't think it fits well with the rest of the language; conversions from distinct T to T or vice versa don't have this extra explicitness either, even though the value of a distinct T might not have any meaningful relation to it's value as T.

[timotheecour]

(let's followup in nim-lang/RFCs#294 (comment) instead to avoid duplicating the discussion)