• Johan Engelen (15/15) Jul 14 2017 The frontend is automatically deducing things like @nogc and
• Walter Bright (2/6) Jul 14 2017 At the moment you can work around it by explicitly adding the annotation...
• Johan Engelen (21/29) Jul 15 2017 Cannot add something to a compiler internal function (e.g.
• Nicholas Wilson (5/21) Jul 15 2017 Not that it helps you at the moment, but thus is addressed by my
• Walter Bright (2/9) Jul 15 2017 https://github.com/dlang/dmd/pull/6995

Johan Engelen <j j.nl> writes:

The frontend is automatically deducing things like  nogc and 
nothrow, but it is flaky and results in linker errors for a 
complex codebase (Weka's).

What happens in that in one kind of compilation,  nogc is deduced 
for a function. But in another compilation, it isn't. Thus 
references to the function will have the wrong mangling, and 
linker errors happen:
https://issues.dlang.org/show_bug.cgi?id=17541

This is blocking upgrading to a newer compiler with a newer 
frontend (2.071 --> 2.073).
(I already have a large amount of work arounds... Also non-user 
functions have this problem, e.g. there is a nothrow deduction 
problem for __fieldPostblit.)

Thanks for looking into this bug.

- Johan

Walter Bright <newshound2 digitalmars.com> writes:

On 7/14/2017 9:53 AM, Johan Engelen wrote:
 What happens in that in one kind of compilation,  nogc is deduced for a 
 function. But in another compilation, it isn't. Thus references to the
function 
 will have the wrong mangling, and linker errors happen:
 https://issues.dlang.org/show_bug.cgi?id=17541

At the moment you can work around it by explicitly adding the annotation.

Johan Engelen <j j.nl> writes:

On Friday, 14 July 2017 at 23:51:24 UTC, Walter Bright wrote:
 On 7/14/2017 9:53 AM, Johan Engelen wrote:
 What happens in that in one kind of compilation,  nogc is 
 deduced for a function. But in another compilation, it isn't. 
 Thus references to the function will have the wrong mangling, 
 and linker errors happen:
 https://issues.dlang.org/show_bug.cgi?id=17541

 At the moment you can work around it by explicitly adding the 
 annotation.

Cannot add something to a compiler internal function (e.g. 
__fieldPostblit),  nogc and pure are infectious, the templates 
are instantiated with different types where some instantiations 
require deducing  nogc/pure/..., others require  gc/impure/..., 
annotations cannot be applied conditionally (at least I don't 
know how), cannot add  gc, cannot add  impure, etc.

My current workarounds force deduction one way or another, but 
it's definitely not nice and it is very time consuming to figure 
out what tricks the compiler into doing the right thing. Each 
error needs it's own special work around.
For example, working around the __fieldPostblit deduction problem 
involved searching all member fields (and their members, etc.) to 
try to find which this(this) should be annotated to fix things. 
Not so nice to do for a somewhat complex struct in a 9MB D-code 
base, sprinkled with conditional compilation, templates, CTFE... 
Each trial build (incremental) takes approx a minute. Fun times.

Fortunately, it looks like I've "fixed" all issues and we can now 
link; kicked of the testing, let's hope there are not too many 
regression bugs at runtime.

-Johan

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

On Saturday, 15 July 2017 at 12:29:09 UTC, Johan Engelen wrote:
 On Friday, 14 July 2017 at 23:51:24 UTC, Walter Bright wrote:
 On 7/14/2017 9:53 AM, Johan Engelen wrote:
 What happens in that in one kind of compilation,  nogc is 
 deduced for a function. But in another compilation, it isn't. 
 Thus references to the function will have the wrong mangling, 
 and linker errors happen:
 https://issues.dlang.org/show_bug.cgi?id=17541

 At the moment you can work around it by explicitly adding the 
 annotation.

 Cannot add something to a compiler internal function (e.g. 
 __fieldPostblit),  nogc and pure are infectious, the templates 
 are instantiated with different types where some instantiations 
 require deducing  nogc/pure/..., others require  gc/impure/..., 
 annotations cannot be applied conditionally (at least I don't 
 know how), cannot add  gc, cannot add  impure, etc.

Not that it helps you at the moment, but thus is addressed by my 
attributes DIP.

I suppose you could abuse  allocSize to force  gc, but thats very 
ugly.

Walter Bright <newshound2 digitalmars.com> writes:

On 7/14/2017 4:51 PM, Walter Bright wrote:
 On 7/14/2017 9:53 AM, Johan Engelen wrote:
 What happens in that in one kind of compilation,  nogc is deduced for a 
 function. But in another compilation, it isn't. Thus references to the 
 function will have the wrong mangling, and linker errors happen:
 https://issues.dlang.org/show_bug.cgi?id=17541

 
 At the moment you can work around it by explicitly adding the annotation.

https://github.com/dlang/dmd/pull/6995