https://issues.dlang.org/show_bug.cgi?id=13742

--- Comment #1 from Martin Nowak <code@dawg.eu> ---
Another occurence of this issue. https://github.com/kiith-sa/D-YAML/issues/20

--

https://issues.dlang.org/show_bug.cgi?id=13742

jiki@red.email.ne.jp changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jiki@red.email.ne.jp

--- Comment #2 from jiki@red.email.ne.jp ---
I hit this on Windows.
Reduced test case is here.


COMMAND:
dmd -cov -g -c test.d f.d
dmd -cov -g -main test.obj f.obj

OUTPUT:
 Error 42: Symbol Undefined ___coverage
--- errorlevel 1

SOURCE FILES:
f.d
---------------------
import std.algorithm;

void func(alias pred)()
{
    int[] range;
    range.find!pred(0);
}
---------------------

test.d
---------------------
import f;

enum mypred = (int a, int b)=>false;
//bool mypred(int a, int b) { return false; } -- WORK AROUND

void test()
{
    func!mypred();
}
---------------------

--

https://issues.dlang.org/show_bug.cgi?id=13742

--- Comment #3 from Martin Nowak <code@dawg.eu> ---
(In reply to jiki from comment #2)
> I hit this on Windows.
> Reduced test case is here.

Also confirmed for linux.
A temporary workaround for your case is to only generate a single object file.

dmd -cov -g -c -oftmp.o test.d f.d
dmd -cov -g -main tmp.o

Hope that also works on Windows.

--

https://issues.dlang.org/show_bug.cgi?id=13742

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=13742

Marc Schütz <schuetzm@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schuetzm@gmx.net

--

https://issues.dlang.org/show_bug.cgi?id=13742

Sönke Ludwig <sludwig@outerproduct.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sludwig@outerproduct.org

--- Comment #4 from Sönke Ludwig <sludwig@outerproduct.org> ---
For completeness sake, this is what I reduced from vibe.d:

foo.d
---
import bar;
void clear() {
  void foo() {}
  performLocked!(() => foo);
}
---

bar.d
---
import core.thread;
void performLocked(alias PROC)() { assert(false); }
---

main.d
---
import foo;
void main() {}
---

dmd -lib -oflib.a bar.d foo.d -cov
dmd -oftest lib.a main.d -cov
-> lib.a(foo.o):foo.d:function
_D3bar50__T13performLockedS28_D3foo5clearFZ9__lambda2MFZvZ13performLockedMFNaNbNiNfZv:
error: undefined reference to '__coverage'

--

https://issues.dlang.org/show_bug.cgi?id=13742

Luís Marques <luis@luismarques.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis@luismarques.eu

--

https://issues.dlang.org/show_bug.cgi?id=13742

Les De Ridder <dlang@lesderid.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlang@lesderid.net

--

https://issues.dlang.org/show_bug.cgi?id=13742

--- Comment #5 from Martin Nowak <code@dawg.eu> ---
Apparently happens because the __coverage symbols is defined twice in foo.o (2.078.0), once as BSS symbols and once as undefined symbol.

nm lib.a

foo.o:
0000000000000000 t
0000000000000000 d __bcoverage
0000000000000000 b __coverage
                 U __coverage
                 U _D3bar12__ModuleInfoZ

Interestingly works when you swap foo.d and bar.d on the command line.

--

https://issues.dlang.org/show_bug.cgi?id=13742

--- Comment #6 from Martin Nowak <code@dawg.eu> ---
The problem seems to be that the `performLocked!(() => foo);` has a location in
bar.d and tries to increment bar's location, but the bar object is already
emitted.
When objects are done all symbols get reset and further references from other
objects add an external undefined symbol, this seems to trigger the linker bug.

As __coverage is local (static) symbol, referencing it from another object file isn't possible atm. anyhow.

So I think the root cause is that the compile order bar.d foo.d ends up moving the nested template function

pure nothrow @nogc @safe void
bar.performLocked!(foo.clear().foo()).performLocked(int)

to the foo.o object, where it can no longer reference bar.d's coverage symbol.

--