fix Issue 21585 - add __traits(totype, string) to convert mangled typ…

[WalterBright]

…e string to an existing type

This is quite a bit simpler than its previous incarnation #11797

But it has a problem. @andralex wrote #11797 (comment) that __traits can return a type. Oops, it cannot, it only returns an Expression. So, there are two options:

1. Return a string. This means to turn the string into a type requires a mixin which can fail if the symbols making up the type are not in scope. Besides, doing a mixin is expensive at compile time, especially when we already have the desired type.
2. Return a TypeExp. TypeExp is a hack in the compiler to treat a type as if it were an expression. But oops, that doesn't work when a type is demanded by the grammar. The solution you can see in the test case is to pass the TypeExp through a template to convert it to an actual Type that can be used wherever a Type is in the grammar. This is what I chose. We can hide this wacky thing inside a nice template and put it in Phobos.

In the future we can perhaps enhance the grammar to extend Type to include __traits(toType, string).

I'll do a spec PR if this is approved.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21585	enhancement	add __traits(totype, string) to convert mangled type string to an existing type

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#12156"

[BorisCarvajal]

@WalterBright you can parse the trait as type with this little patch, no need to use templates.

BorisCarvajal@5eaea1c

[PetarKirov]

As proposed in the previous PR, I think we should overload based on the last argument to this trait:

__traits(toType, string) :: string -> type
__traits(toType, arrayOfStrings) :: string[] -> (__traits(toType, strings[0]), __traits(toType, strings[1]), ... __traits(toType, strings[$ - 1]))

The motivation is that __traits(toType) would likely be used heavily in the inner loops of meta-programming templates and such it's important to optimize for the case of arrays of mangled type names. This way we can avoid one more levels of unnecessary template wrappers.

[WalterBright]

@BorisCarvajal @PetarKirov these are both good ideas and would make good follow-on PRs.

[PetarKirov]

Please add:

• an additional fail test to cover all code paths
• a test shows "importing" a private type by it's mangled name.
• __traits(toType, magledNameOfTypeFromAnotherModule) - to test the limits of this feature - what happens if you "import" a type from a module that is not being compiled

Otherwise the current implementation looks good to me - simple, but powerful.

[RazvanN7]

The decoToType function would sit better in traits.d. It is the only place where it is called and therefore it can be made private. Plus, we get rid of the import in dmangle.d as traits.d already imports it.

[RazvanN7]

Ping @WalterBright

[WalterBright]

ping @RazvanN7

[rainers]

I'm afraid this will disappoint too easily, as the compiler needs to have seen the exact type in advance, e.g.

pragma(msg, __traits(toType, "Pi"));
int* p;
pragma(msg, typeof(p).mangleof);

yields

totype.d(1): Error: cannot determine `__traits(toType, "Pi")`
totype.d(1):        while evaluating `pragma(msg, __traits(toType, "Pi"))`
Pi

It passes if p is declared before the trait.

[rainers]

BTW: the example from the bugzilla entry doesn't compile:

__traits(toType, "i") x;         // declares `x` as having type `int`

results in

totype.d(2): Error: trait `toType` is either invalid or not supported as type

[WalterBright]

the example from the bugzilla entry doesn't compile

That's because the Type template is needed, as in the test case in this PR.

[WalterBright]

It passes if p is declared before the trait

That's right. Unfortunately, there's not an obvious way around the compiler has to see the type before it can demangle it.

[rainers]

That's because the Type template is needed, as in the test case in this PR.

I think toType is missing here: https://github.com/dlang/dmd/blob/master/src/dmd/typesem.d#L1762

[rainers]

Unfortunately, there's not an obvious way around the compiler has to see the type before it can demangle it.

That makes it very difficult to find a compelling use case for this addition.

Maybe it is possible to pass a type as a string to a CTFE function to generate a mixin that allows the mixin to be instantiated anywhere, even if the type is unknown at the point of instantiation. I think this should be explored before merging and should be demonstrated as a test case.

[WalterBright]

@rainers I didn't know that dmd was changed to allow __traits to act as a type. So I fixed this PR per your suggestion.

addressed requested changes in the comments

[RazvanN7]

Why not move this function to traits.d ? Then it can be made private.

[WalterBright]

Because traits.d is plenty large enough, and it would be best suited to be with the mangling code.

[maxhaton]

I read the original thread, but I still don't think I see what the rationale is here?

[WalterBright]

I still don't think I see what the rationale is here?

Provide symmetry to .mangleof. Trying to do this without compiler support would be tedious, slow and fragile.

[maxhaton]

I still don't think I see what the rationale is here?

Provide symmetry to .mangleof. Trying to do this without compiler support would be tedious, slow and fragile.

OK. I was just making sure I hadn't missed some uber-useful thing buried in the thread/s somewhere. TypeExp seems a bit of a hack to my eye, is there a long term alternative in the compiler as-is?

[WalterBright]

TypeExp has been there a long time, it is there to deal with the cases of ambiguity in the grammar.