[dmd-internals] 5th Biweekly Sprint Planning​

[Martin Nowak via dmd-internals]

On 09/09/2015 08:15 PM, Andrei Alexandrescu wrote:
> I haven't followed this very closely so please correct me if my
> perception is wrong. It seems that template instantiations has been
> fixed many times over the past many months (perhaps a year's time) and
> every time it was, new regressions were introduced that in turn needed
> more fixes.

They always have been broken (e.g. multiple object files with -c), but
the real issues began with
https://github.com/D-Programming-Language/dmd/pull/2550 where we would
instantiate a lot less templates by making assumptions about templates
already being instantiated in a library.
This provided a significant speedup but comes with lots of subtle corner
cases.

> I don't know how templates instantiation is currently implemented, but I
> can recognize the pattern because I've seen it (sadly) many times: it's
> the sign of a design that got to a catastrophic failure stage, in which
> the rate of defects outpaces the rate of patching and fixing them.

The issues are getting smaller (edge edge cases) but we're overfitting
the implementation to the test cases instead of generalizing the
specification.
There is indeed way too much complexity buried in the template
implementation (maybe the design as well). This has always been the case
and I made a proposal to restucture the implementation
(https://github.com/D-Programming-Language/dmd/pull/4780#issuecomment-124087604).

> It seems to me it's time for a complete rethinking/redesign of template
> instantiation. A design that's comprehensible and robust and solves our
> perennial problems naturally (bloated object files, unnecessary work
> leading to slow compiles, linking issues, etc). What are the core
> compiler folks' thoughts on making this a priority?

It's definitely on the agenda but doesn't preclude working on the
current implementation b/c it's unclear whether we can actually come up
with a feasible and better solution.

-Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20150909/87e48185/attachment.sig>