use special enums for __c_long, etc. instead of special structs

[WalterBright]

The existing mechanism is in core.stdc.config, which uses a struct named __c_long. This change enables using an enum instead, which has some advantages:

• enums are a lot closer to typedefs
• we can allow implicit conversion of other integers to these special enums
• linking with druntime will not be required

Later we can do away with core.stdc.config entirely and just predefine these enums in the compiler.

The tests will be when core.stdc.config is redone using enums, which will be the egg (or the chicken?).

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

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

dub fetch digger
dub run digger -- build "master + dmd#8152"

[jacob-carlborg]

How will the usage of this look like?

[kinke]

I guess something like

enum __c_long : long;
alias c_long = __c_long;
void foo(c_long c);
void bar() { foo(123); }

I suggest adding special IDs __c_(u)longlong too, as a C++ long long cannot be represented in D for 64-bit Posix targets (excl. macOS after the 2.079 mangling change).

[jacob-carlborg]

enum __c_long : long;
alias c_long = __c_long;

void foo(c_long a){};

void main()
{
   foo(3L);
}

The above results in:

Error: function main.foo (__c_long a) is not callable using argument types (long)

[jacob-carlborg]

@WalterBright would you consider trying to get this working instead #7458? That is, adding support for pragma(mangle) to alias declarations.

[WalterBright]

That is, adding support for pragma(mangle) to alias declarations.

It's completely antiethical to the way alias works. Aliases are internally instantly replaced with their aliased type all through the compiler. Enums are not, which is why doing special enums is a very small change.

[jacob-carlborg]

What's the advantage of using an enum instead of a struct?

[jacob-carlborg]

It's completely antiethical to the way alias works. Aliases are internally instantly replaced with their aliased type all through the compiler. Enums are not, which is why doing special enums is a very small change.

That might be the case but it would be very convenient.

[WalterBright]

What's the advantage of using an enum instead of a struct?

• enums are a lot closer to typedefs
• we can allow implicit conversion of other integers to these special enums
• linking with druntime will not be required

[rainers]

The tests will be when core.stdc.config is redone using enums, which will be the egg (or the chicken?).

You can add the enum declarations into the test file right now. This is currently done for the struct version in cppa.d.

[WalterBright]

Ok I added some tests to cppa.d

[jacob-carlborg]

Can you add a usage test as well that verifies that the implicit conversions work too.

[ibuclaw]

One thing that I don't think is handled here but probably will need to be in druntime are type properties. Wouldn't you need to declare enum members named init, max, min, etc... Unless there is special handling in the compiler that I'm not seeing here.

[ibuclaw]

I take it that tydouble is correct here, and that there is no long double ty.

[WalterBright]

There is a TYdouble_alias, but it is used by the dmc++ front end to do name mangling. The code generator doesn't care - the dmd front end does the name mangling.

[jacob-carlborg]

What's the reasoning for the version statement? Will this test be run on a compiler that doesn't contain this change?

[WalterBright]

Can't have two global declarations of __c_long, etc.

[WalterBright]

Unless there is special handling in the compiler that I'm not seeing here.

The .init was there, but not .max/.min. I added them.