Generate TypeInfo objects as in template instances

[9rnsr]

TypeInfos and template instances are very similar, they are "generated" when the type is used ≒ the template is instantiated. And they are placed in COMDAT section to allow objcode duplication from each compilations.

From 2.064, dmd has supported strict instantiation algorithm (#2550) to reduce executable size. I think we should modify TypeInfo generation algorithm to follow it.

From Walter's suggestion (#2480 (comment)), this PR still supports old sloppy TypeInfo generation algorithm by -allinst switch.

This PR is based on #3948.

[rainers]

I guess the build failures are caused by core.sys.linux.link and others not being part of the files to be compiled into druntime, but only merely imported. This is expected.

However, I compiled this PR for Win32, and added checks for non-existing RTInfo as in #2480. The unittests build, but running the tests caused these error when building d_do_test:

m:/s/d/rainers/windows/bin/dmd.exe -odtest_results -oftest_results\\d_do_test.exe d_do_test.d
m:\s\d\rainers\phobos\std\regex.d(588): Error: ICE: no RTInfo generated for NamedGroup
m:\s\d\rainers\phobos\std\regex.d(399): Error: ICE: no RTInfo generated for Bytecode
m:\s\d\rainers\phobos\std\internal\unicode_tables.d(49): Error: ICE: no RTInfo generated for UnicodeProperty
m:\s\d\rainers\phobos\std\uni.d(5803): Error: ICE: no RTInfo generated for DecompressedIntervals
m:\s\d\rainers\phobos\std\uni.d(1976): Error: ICE: no RTInfo generated for InversionList
m:\s\d\rainers\phobos\std\uni.d(3109): Error: ICE: no RTInfo generated for CowArray

[rainers]

I've updated druntime locally to build anything from the MANIFEST file and could build d_do_test (no idea how this is related), but now the test suite fails (with the RTInfo check):

m:\s\d\rainers\windows\bin\dmd.exe -m32 -Irunnable  -g -allinst -odtest_results\runnable -c runnable\test11447c.d
runnable\imports\c11447.d(44): Error: ICE: no RTInfo for B

It shows that using -allinst for TypeInfo does not really work, because it can generate wrong TypeInfo.
If I disable the allinst code in typinf.c, the test suite passes.

[rainers]

I added the "Needs Approval" label because this PR changes what files need to be compiled.
Now, "header" only files will also need to be compiled if the TypeInfo of structs with zero-initializers are used anywhere. It was necessary for non-zero-initialized structs before.

[rainers]

Can we move forward with this? Does it need a forum discussion?

I implemented a different RTInfo for a variant of the precise GC, that is just a bit more complex and hit more link errors which #2480 could not fix. #2480 fights the symptoms, as many other fixes have tried with respect to TypeInfo, opEqual, opCmp, etc. The approach here removes the root of the problem, though it changes use of di-files slightly.

[JinShil]

I just ran across this pull request by accident, and I'm wondering if it would help a address a problem that I'm currently facing with TypeInfo.

I'm trying to use D for bare-metal, resource-constrained embedded systems (Proof of concept). Due to the way TypeInfo is generated, my static memory-mapped IO code makes my binary about 100 times larger than it should be (400K vs 6K). It's a deal-breaker for me, and I've been stalled in my work for going on a year. I've filed a GDC bug report, and I've spent the last month trying to implement Enhancement 12270 - Move TypeInfo to the D Runtime without success.

I'm not qualified to understand this implementation and what it specifically provides, so I ask: Would this pull request help tame TypeInfo or make the implementation of Ehnhacement 12270 more feasible?

Please advise. I'm desperate for a solution to this. I haven't been able to move forward with my ideas for almost a year because of this problem.

[MartinNowak]

Related to #4780 and #4784.

[9rnsr]

This is outdated.