fix Issue 21932 ImportC: enum ENUM conflicts with enum ENUM

[WalterBright]

Fixing the bug meant revamping how enums were done:

1. Treat them analogously to structs
2. Fix errors with redeclaring a union tag as an enum tag
3. Instead of manifest constant declarations, use alias declarations
4. Give errors for incomplete enum declarations
5. Fix failure to distinguish union tags from struct tags
6. Uses D's semantic analyzer for enums, which gives the D side access to things like the .max property

Todo: enum base types are still int. Need to figure out just what gcc's wrongly documented rule is for determining the base type (it doesn't match gcc's behavior). The C11 spec is self-contradictory on this issue.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21932	critical	importC: enum 'ENUM' conflicts with enum 'ENUM'

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#12787"

[WalterBright]

This is not a critical bug. Lowered to normal.

[thewilsonator]

Please fix the typo in the title and commit message.

[ibuclaw]

Anything going to end up here? Otherwise just remove it.

[WalterBright]

I left that there just to point out that I had not forgotten about that case.

[ibuclaw]

Todo: enum base types are still int. Need to figure out just what gcc's wrongly documented rule is for determining the base type (it doesn't match gcc's behavior). The C11 spec is self-contradictory on this issue.

Just use the same logic as how what type an integer literal should be. Though I'm curious how it deals with both a signed and unsigned value as members. With 32-bit in, I assume it would go up to 64-bit long, but from there, would it pick 128-bit cent?

Edit: Seems to be warn and overflow

warning: integer constant is so large that it is unsigned
     |   slong = -9223372036854775808L,
     |            ^~~~~~~~~~~~~~~~~~~~
warning: enumeration values exceed range of largest integer
     | };
     | ^
{
  TestEnum a = -2147483648;
  TestEnum b = 4294967295;
  TestEnum c = -9223372036854775808;
  TestEnum d = -1(OVF);

  return 8;
}

[ibuclaw]

Just use the same logic as how what type an integer literal should be.

Saying that, we do have IntRange which should allow us to do something like...

const enumrange = IntRange(SignExtendedNumber(ed.minval.getInteger()),
                           SignExtendedNumber(ed.maxval.getInteger()));
if (IntRange.fromType(Type.tuns32).contains(enumrange))
    type = Type.tuns32;
else if (IntRange.fromType(Type.tint32).contains(enumrange))
    type = Type.tint32;
else if (IntRange.fromType(Type.tuns64).contains(enumrange))
    type = Type.tuns64;
else
    type = Type.tint64;

[WalterBright]

I thought I'd use the "common type" logic one gets with A + B + C + D to determine the final type of the entire expression. This would make it consistent and unsurprising.

[WalterBright]

But that's a problem for a separate PR.

[ibuclaw]

But that's a problem for a separate PR.

Sure, so long as there's room to add support for ARM short enums afterwards, then it will be fine.

[ibuclaw]

Note, hidden string comparison.

[WalterBright]

Not exactly, as D merges string duplicates.

[ibuclaw]

Only if they appear in the same compilation unit.