Function attribute deduction depends on compile invocation

[Johan Engelen via Digitalmars-d]

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