On Wednesday, 21 June 2017 at 00:08:24 UTC, Mike wrote:
GDC may have fixed the problem recently with [2], but I haven't
tested it. Lucia Cojocaru is (was?) also working on addressing
the problem by lowering TypeInfo calls in the compiler to
templates [3].
I've decoupled the code generating compiler (gdc) from runtime
(druntime), and will generate pseudo typeinfo if any are missing
- this is in contrast to dmd which would complain about missing
TypeInfo/corrupt object.d.
This should mean that object.d can be distilled down to just:
module object;
class Object { }
From a minilibd perspective, and the compiler will just fill in
the blanks and continue without complaint. However you'll still
get linker errors if you don't define TypeInfo anywhere. (If
there are any other compile-time errors, it's likely the dmd
front-end complaining because it can't generate some artificial
helper function).
Pay-as-you-go TypeInfo generation could be done stemming from
this. Currently, the strategy is to always generate TypeInfo in
the module that "owns" the type, on premise that although it may
not be used itself, some external module may want it.
Really though, this is probably about as far as I can push it
without making changes to the dmd frontend or druntime library
itself. IMO the right thing to do is to not push the compiler,
but to push the D runtime library into improving it's runtime
interface.
i.e: https://github.com/dlang/druntime/pull/1792
Replacing the old legacy functions with templates that don't
require typeinfo is the direction that people should be pushing
in. Without this, I can't see -fno-rtti being possible without
severely restricting users to a slim subset.
Regards,
Iain.
