How to get to a class initializer through introspection?

[Johan]

On Wednesday, 5 August 2020 at 13:40:16 UTC, Johannes Pfau wrote:
>
> I'd therefore suggest the following:
> 1) Make all init symbols COMDAT: This ensures that if a smybol 
> is
> actually needed (address taken, real memcpy call) it will be 
> available.
> But if it is not needed, the compiler does not have to output 
> the symbol.
> If it's required in multiple files, COMDAT will merge the 
> symbols into
> one.
>
> 2) Ensure the compiler always knows the data of that symbol. 
> This probably means during codegen, the initializer should 
> never be an external symbol. It needs to be a COMDAT symbol 
> with attached initializer expression. And the initializer data 
> must always be fully available in .di files.
>
> The two rules combined should allow the backend to choose the 
> initialization method that is most appropriate for the target 
> architecture.

What you are suggesting is pretty much exactly what the compilers 
already do. Except that we don't expose the initialization symbol 
directly to the user (T.init is an rvalue, and does not point to 
the initialization symbol), but through TypeInfo.initializer. Not 
exposing the initializer symbol to the user had a nice benefit: 
for cases where we never want to emit an initializer symbol (very 
large structs), we simply removed that symbol and started doing 
something else (memset zero), without breaking any user code. 
However this only works for all-zero structs, because 
TypeInfo.initializer must return a slice ({init symbol, length}) 
to data or {null,length} for all-zero (the 'null' is what we 
started making use of). More complex cases cannot elide the 
symbol.

Initializer functions would allow us to tailor initialization for 
more complex cases (e.g. with =void holes, padding schenanigans, 
or non-zero-but-repetitive-constant double[1million] arrays, 
...), without having to always turn-on some backend optimizations 
(at -O0) and without having to expose a TypeInfo.initializer 
slice, but instead exposing a TypeInfo.initializer function 
pointer.

-Johan