Jump to page: 1 2 3
Thread overview
Phobos: __FILE__ as template default parameter
Jun 18, 2016
Johan Engelen
Jun 18, 2016
Johan Engelen
Jun 19, 2016
Lass Safin
Jun 19, 2016
Dicebot
Jun 19, 2016
Johan Engelen
Jun 19, 2016
Dicebot
Jun 20, 2016
Jacob Carlborg
Jun 20, 2016
Simen Kjaeraas
Jun 21, 2016
ZombineDev
Jun 21, 2016
ZombineDev
Jun 21, 2016
pineapple
Jun 21, 2016
pineapple
Jun 21, 2016
ZombineDev
Jun 19, 2016
Dicebot
Jun 19, 2016
Johan Engelen
Jun 19, 2016
Johan Engelen
Jun 19, 2016
David Nadlinger
Jun 19, 2016
Johan Engelen
Jun 20, 2016
Dicebot
Jun 21, 2016
David Nadlinger
Jun 22, 2016
Johan Engelen
Jul 05, 2016
Johan Engelen
June 18, 2016
In std.exception, there are two functions that still take __FILE__ as default template parameter;

T enforce
    (T, Dg, string file = __FILE__, size_t line = __LINE__)
    (T value, scope Dg dg)

T errnoEnforce
    (T, string file = __FILE__, size_t line = __LINE__)
    (T value, lazy string msg = null)

The second one has caused me hours of pain :(
The template parameters end up in the symbol's mangled name, and besides the resulting template bloat (a new instantiation for each "errnoEnforce") it means that the source path is hard-encoded into a few function symbols in Phobos (interestingly not for DMD, but it is for the way LDC builds the Phobos lib it ships with). And so while working on (aggressive) cross-module inlining in LDC (it's working now!), I stumbled on linker errors because the symbols were missing --> they are there but with a different phobos path encoded in them!

All this to say:
  I hope someone can deprecate these two guys from Phobos, and replace them with functions that take __FILE__ as runtime parameter. (See the `enforce` that does not take a delegate as second parameter).

Thanks!
  Johan

(I'll have to work around this in LDC regardless. It'll mean that whenever you use __FILE__ as template parameter, that the calling function can not be inlined.)
June 18, 2016
An example of how __FILE__ as template parameter will break your library:

In library, distributed in binary+source form:
```
alias file_templ_alias = file_templ!bool;
T file_templ(T, string file = __FILE__, size_t line = __LINE__) (T value) {
    return value;
}
```
In user code, linking to the library binary:
```
bool foo(bool b){
    return file_templ_alias(b);
}
```
By calling the alias, both DMD and LDC will decide that the template does not need reinstantiation in the user object file and will try to link with the symbol in the library binary. So you have to be lucky to install the library source in the same path as where it was when the library was built on someone else's machine, otherwise you'll get a linker error and are left wondering what went wrong.

-Johan
June 19, 2016
This important feature and can't be simply removed. For example, std.experimental.logger also relies on it. It needs to be fixed instead.

Two immediate workarounds that come to mmy mind:

1. Make __FILE__ relative to import path
2. Always emit new symbol to object file if __FILE__ is involved
June 19, 2016
On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
> This important feature and can't be simply removed. For example, std.experimental.logger also relies on it.

Do you mean it relies on __FILE__ being a template parameter (instead of a runtime default parameter, like enforce)?

> It needs to be fixed instead.
>
> Two immediate workarounds that come to mmy mind:
>
> 1. Make __FILE__ relative to import path
> 2. Always emit new symbol to object file if __FILE__ is involved

I also thought about 2. It would fix the second (non-Phobos) example.

-Johan
June 19, 2016
On Sunday, 19 June 2016 at 08:33:40 UTC, Johan Engelen wrote:
> On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
>> This important feature and can't be simply removed. For example, std.experimental.logger also relies on it.
>
> Do you mean it relies on __FILE__ being a template parameter (instead of a runtime default parameter, like enforce)?

Yes. It is necessary because runtime parameter list is variadic - template bloat in such cases is usually eliminated by forwarding to another private method immediately turning file/line into first runtime argument instead.

>> It needs to be fixed instead.
>>
>> Two immediate workarounds that come to mmy mind:
>>
>> 1. Make __FILE__ relative to import path
>> 2. Always emit new symbol to object file if __FILE__ is involved
>
> I also thought about 2. It would fix the second (non-Phobos) example.
>
> -Johan


June 19, 2016
On 06/19/2016 11:33 AM, Johan Engelen wrote:
> On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
>> This important feature and can't be simply removed. For example, std.experimental.logger also relies on it.
> 
> Do you mean it relies on __FILE__ being a template parameter (instead of a runtime default parameter, like enforce)?
> 
>> It needs to be fixed instead.
>>
>> Two immediate workarounds that come to mmy mind:
>>
>> 1. Make __FILE__ relative to import path
>> 2. Always emit new symbol to object file if __FILE__ is involved
> 
> I also thought about 2. It would fix the second (non-Phobos) example.
> 
> -Johan

Another option would be to treat functions relying on __FILE__ as template argument as force inline ones.

June 19, 2016
On Sunday, 19 June 2016 at 20:37:02 UTC, Dicebot wrote:
> On 06/19/2016 11:33 AM, Johan Engelen wrote:
>> On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
>>> This important feature and can't be simply removed. For example, std.experimental.logger also relies on it.
>> 
>> Do you mean it relies on __FILE__ being a template parameter (instead of a runtime default parameter, like enforce)?
>> 
>>> It needs to be fixed instead.
>>>
>>> Two immediate workarounds that come to mmy mind:
>>>
>>> 1. Make __FILE__ relative to import path
>>> 2. Always emit new symbol to object file if __FILE__ is involved
>> 
>> I also thought about 2. It would fix the second (non-Phobos) example.
>> 
>> -Johan
>
> Another option would be to treat functions relying on __FILE__ as template argument as force inline ones.

Yes, but it's a flaky solution I think.
For LDC that would work (I think we can pretty much inline anything the user throws at us). I don't know about DMD.
June 19, 2016
On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
> (I think we can pretty much inline anything the user throws at us)

(as long as it is not a naked asm function)


June 19, 2016
On Sunday, 19 June 2016 at 21:13:00 UTC, Johan Engelen wrote:
> On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
>> (I think we can pretty much inline anything the user throws at us)
>
> (as long as it is not a naked asm function)

Another example is `alloca`, which you might not want to inline.

 — David
June 19, 2016
On Sunday, 19 June 2016 at 21:40:20 UTC, David Nadlinger wrote:
> On Sunday, 19 June 2016 at 21:13:00 UTC, Johan Engelen wrote:
>> On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
>>> (I think we can pretty much inline anything the user throws at us)
>>
>> (as long as it is not a naked asm function)
>
> Another example is `alloca`, which you might not want to inline.

And also variadic functions, for which Dicebot needs __FILE__ to be a template param..............
« First   ‹ Prev
1 2 3