Am Wed, 8 Jan 2014 01:15:32 +0000 schrieb Iain Buclaw <[email protected]>:
> > If you use a struct, it generates typeinfo and initialiser symbols > that go on the comdat on the basis that you *may* access the typeinfo > at runtime. > > These are weak decls so the linker merges/removes duplicates. There's > currently no solution in which the compiler decides whether to omit > sending the symbols to object file, but this can be worked upon. I think there are three steps to make TypeInfo completely optional * -fno-typeinfo as a global switch instructing the compiler that it _never_ has typeinfo and should never output typeinfo. In this case all files must be compiled consistently with -fno-typeinfo or without it Useful to disable all TypeInfo generation even if the runtime has typeinfo support * pragma(notypeinfo)/@attribute(notypeinfo) as in LDC Useful to exclude typeinfo for specific types * A way for the runtime to say 'I don't support TypeInfo' Basically introducing 'core.config' with 'enum RuntimeSupportsTypeInfo = false;'. If the compiler finds this declaration it should automatically use '-fno-typeinfo' 'core.config' could then also be used with RuntimeSupportsGC, RuntimeSupportsUTF (switches over strings, IIRC) and similar things. A minimal runtime would just set all those variables to false and the compiler could automatically use a restricted set of D (nogc/no string switches/...) > > I think the best logical steps to go down, is that you should write a > replacement for the core library functions that the compiler > implicitly calls (_d_arrayliteralX, _d_arraycopy, _d_newclass, > _d_newitemT, etc), but omit using the TypeInfo parameter. Once you > feel that it is ready, then we can add a switch into the compiler > that: > 1) Doesn't generate typeinfo > 2) Passes a null pointer as the typeinfo parameter to the Druntime > library calls. > > Object _d_newclass(const ClassInfo ci) -> Object _d_newclass() > IIRC Andrei wants _d_newclass to be independent of ClassInfo anyway (by making it a template). I think this came up when we talked about replacing 'new' with a library template or in a custom allocator discussion or something. There were already approaches making associative arrays a templated library type. Then we could just as well make normal arrays a templated library type and avoid typeinfo there. Runtime variadic arguments need typeinfo IIRC. We'd have to ban calling those functions with -fno-typeinfo or if any of the arguments was declared with @attribute(notypeinfo)
