Thread overview
add -allinst compiler switch
Oct 18, 2013
Walter Bright
Oct 18, 2013
Max Samukha
Oct 18, 2013
Iain Buclaw
Oct 18, 2013
Jacob Carlborg
Oct 18, 2013
Dicebot
Oct 20, 2013
Denis Shelomovskij
October 18, 2013
Explained here:

http://d.puremagic.com/issues/show_bug.cgi?id=11284

It's a bit complicated, and important.

BTW, I hate the name of the switch, but haven't thought of anything better.
October 18, 2013
On Friday, 18 October 2013 at 07:17:12 UTC, Walter Bright wrote:
> Explained here:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11284
>
> It's a bit complicated, and important.
>
> BTW, I hate the name of the switch, but haven't thought of anything better.

A good start would be to have the issues thoroughly explained in the documentation. As far as I know, no article on templates mentions how they are actually compiled.
October 18, 2013
On 18 October 2013 08:17, Walter Bright <newshound2@digitalmars.com> wrote:
> Explained here:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11284
>
> It's a bit complicated, and important.
>
> BTW, I hate the name of the switch, but haven't thought of anything better.

GDC has -femit-templates which emits all templates as private, then
the linker then removes unreferenced templates.  This however is
different from the behavior in 2.063, in that it generates code for
*no really, all* instantiated templates.  This is because of front-end
template bugs when doing separate compilation (especially in
large/complex projects - what you call 'build system irregularities').
 Not sure of what you mean when you say this is the behaviour in
2.063, as if 2.063 *did* emit code for all instantiated templates, I'd
have no need to put in -femit-templates (which emits more code).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
October 18, 2013
On 2013-10-18 13:47, Iain Buclaw wrote:

> GDC has -femit-templates which emits all templates as private, then
> the linker then removes unreferenced templates.  This however is
> different from the behavior in 2.063, in that it generates code for
> *no really, all* instantiated templates.  This is because of front-end
> template bugs when doing separate compilation (especially in
> large/complex projects - what you call 'build system irregularities').
>   Not sure of what you mean when you say this is the behaviour in
> 2.063, as if 2.063 *did* emit code for all instantiated templates, I'd
> have no need to put in -femit-templates (which emits more code).

Perhaps it now emits templates to less object files :)

-- 
/Jacob Carlborg
October 18, 2013
On Friday, 18 October 2013 at 07:17:12 UTC, Walter Bright wrote:
> Explained here:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11284
>
> It's a bit complicated, and important.
>
> BTW, I hate the name of the switch, but haven't thought of anything better.

I'd suggest to also support `-transition=<bugzilla id>` switch added by Kenji for previous release
October 20, 2013
18.10.2013 11:17, Walter Bright пишет:
> Explained here:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11284
>
> It's a bit complicated, and important.
>
> BTW, I hate the name of the switch, but haven't thought of anything better.

Links to user complains are needed or the issue sounds not evident.

E.g. the only issues with dmd object generation change after dmd pull #2550 [1] I have seen are compiler bugs when it incorrectly detects instantiating module (e.g. issues 11069 [2] and 11114 [3]).

Also personally I against supporting incorrect user actions just because it was supported before just like we do every release with fixing "accept-invalid" bugs.

[1] https://github.com/D-Programming-Language/dmd/pull/2550
[2] http://d.puremagic.com/issues/show_bug.cgi?id=11069
[3] http://d.puremagic.com/issues/show_bug.cgi?id=11114

-- 
Денис В. Шеломовский
Denis V. Shelomovskij