add support for Object.RTTypeid template

[WalterBright]

Currently, instances of TypeInfo are generated by a complex and tedious process inside the compiler. This change experiments with using a template in druntime, Object.RTTypeid instead, to generate it. The compiler will know nothing about the contents of TypeInfo, leaving people free to innovate with the definition of RTTypeid. (All that code in the compiler will be removed once RTTypeid is successful.)

This is analogous to the successful use of Object.RTinfo to generate info for the garbage collector. The implementation of RTTypeid is very similar for that for RTinfo, which can be found in Semantic3Visitor in semantic3.d

This PR makes it so that if Object.RTTypeid is not there, it falls back to the original compiler implementation of TypeInfo.

[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 run digger -- build "master + dmd#11459"

[ibuclaw]

Currently, instances of TypeInfo are generated by a complex and tedious process inside the compiler. This change experiments with using a template in druntime, Object.RTTypeid instead, to generate it. The compiler will know nothing about the contents of TypeInfo, leaving people free to innovate with the definition of RTTypeid. (All that code in the compiler will be removed once RTTypeid is successful.)

This is analogous to the successful use of Object.RTinfo to generate info for the garbage collector. The implementation of RTTypeid is very similar for that for RTinfo, which can be found in Semantic3Visitor in semantic3.d

This PR makes it so that if Object.RTTypeid is not there, it falls back to the original compiler implementation of TypeInfo.

So the call to toObjFile is planned to be removed?

[WalterBright]

So the call to toObjFile is planned to be removed?

??

[andralex]

See also: dlang/druntime#3172. Need to fix the associative arrays first.

[adamdruppe]

Doesn't this completely obsolete RTInfo? It is currently just accessible through typeinfo and if typeinfo is itself a template, whatever we want from RTInfo can simply be done in here.

[WalterBright]

@adamdruppe maybe they can be merged in the future.

[WalterBright]

I modified it so if RTTypeid doesn't return a variable, it'll just use the old builtin method. This is so a partial implementation of RTTypeid can be developed.

[andralex]

@WalterBright Thanks, that didn't work with:

template RTTypeid(T)
if (is(T == int))
{
    ...
}

I get a bunch of errors such as:

Error: cannot interpret RTTypeid!(const(char[])) at compile time
Error: cannot interpret RTTypeid!(char[]) at compile time
src/core/demangle.d(2337): Error: template instance core.demangle.mangle!(nothrow @nogc string(string, scope string delegate(string) nothrow @nogc, bool)) error instantiating

They suggest RTTypeid is instantiated with a bunch of types, not just int.

[andralex]

Even simpler to eliminate all possibilities of error:

struct neverusedbyanyone {}
template RTTypeid(T)
if (is(T == neverusedbyanyone))
{
}

causes the same errors

[andralex]

Oh, even simpler:

template RTTypeid(T)
if (false)
{
}

This also causes errors. That's the simplest baseline.

[wilzbach]

So basically until we can switch fully to the auto-generated headers, updates to the frontend header file are a strong indication that the old header files need to be manually updated as well.