D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 14662 - __FILE__ template parameter becomes relative just by changing compilation directory
Summary: __FILE__ template parameter becomes relative just by changing compilation dir...
Status: RESOLVED WONTFIX
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86 All
: P1 major
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-08 04:08 UTC by Timothee Cour
Modified: 2020-03-21 03:56 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Timothee Cour 2015-06-08 04:08:41 UTC
I was getting quite obscure linker errors in a project. I reduced it to this:
__FILE__ generates sometimes relative paths even though all files and '-I' paths are given as absolute paths, depending on the directory in which 'dmd' is launched.



----------------------------
/mydir/fun1.d:
import fun2;
void test(){ test2(); }
/mydir/fun2.d:
void test2(string file=__FILE__)(){
  if(false) test2();
}

-----------------
cd /mydir/
dmd -of/tmp/fun1.o -c -I/mydir/ /mydir/fun1.d && nm /tmp/fun1.o |ddemangle |grep test2
S pure nothrow @nogc @safe void fun2.test2!("/mydir/fun1.d").test2()
S pure nothrow @nogc @safe void fun2.test2!("fun2.d").test2()
-----------------
cd / #or anywhere else

dmd -of/tmp/fun1.o -c -I/mydir/ /mydir/fun1.d && nm /tmp/fun1.o |ddemangle |grep test2
S pure nothrow @nogc @safe void fun2.test2!("/mydir/fun1.d").test2()
S pure nothrow @nogc @safe void fun2.test2!("/mydir/fun1.d").test2()

The difference is: 'test2!("/mydir/fun1.d")' vs 'test2!("fun2.d")'

I believe 'test2!("fun2.d")' is wrong.

Maybe related:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/exclude_current_directory_from_search_path_in_dmd_69919.html "exclude current directory from search path in dmd ?" (which i asked on the forum but didn't get answer to)
Comment 1 Johan Engelen 2016-06-22 20:33:45 UTC
Using __FILE__ as template parameter is definitely bug-prone.

Related forum discussion: https://forum.dlang.org/thread/induraqegvpyomvzxwmf@forum.dlang.org
Comment 2 basile-z 2019-11-24 11:05:13 UTC
there's __FILE_FULL_PATH__ now
Comment 3 johanengelen 2019-11-26 17:13:32 UTC
I still think this is a bug and related bugginess of __FILE__ as mentioned in the forum post. Yes there is __FILE_FULL_PATH__ but that does not help with libraries distributed in binary+.di (include files). See the forum post above for details.