Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
July 14, 2017 Function attribute deduction depends on compile invocation | ||||
---|---|---|---|---|
| ||||
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 |
July 14, 2017 Re: Function attribute deduction depends on compile invocation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | 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.
|
July 15, 2017 Re: Function attribute deduction depends on compile invocation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
July 15, 2017 Re: Function attribute deduction depends on compile invocation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | 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.
|
July 15, 2017 Re: Function attribute deduction depends on compile invocation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
Copyright © 1999-2021 by the D Language Foundation