dirEntries gives link errors (works with dmd, fails with ldmd2)

[timotheecour]

import std.file;
void main(){
    auto a=dirEntries("","",SpanMode.depth);
}

ldmd2 main.d:

Undefined symbols for architecture x86_64:
"__D3std8typecons86__T10RefCountedTS3std4file15DirIteratorImplVE3std8typecons24RefCountedAutoInitialize0Z10RefCounted10__postblitMFZv", referenced from:
__D123TypeInfo_S3std8typecons86__T10RefCountedTS3std4file15DirIteratorImplVE3std8typecons24RefCountedAutoInitialize0Z10RefCounted6__initZ in main.o
ld: symbol(s) not found for architecture x86_64

[redstar]

Confirmed. Happens on Gentoo with ldc2, too.

[nomad-software]

I think i'm experiencing the same issue explained here: http://forum.dlang.org/thread/wzzfsnshgdjdoypanamp@forum.dlang.org#post-qrftnizdsbuimxicolov:40forum.dlang.org

Debian7, llvm-3.4, ldc2

[dnadlinger]

@nomad-software: Yes, this is very likely the same issue.

To fix, we might need to change quite a few things: The basic problem is that we are emitting the definitions for the return type of dirEntries to the module that calls it, as it is a template, but we shouldn't (the functions are guaranteed to be available from std.file because dirEntries itself is a regular function).

The undefined symbol comes from the fact that attribute inference hasn't properly been run on the template yet and thus the mangled name of the function in question doesn't match the one in the std.file object file. I'm not sure whether this is a problem in and of itself, but assuming that the only reasonable fix in the short term is to match DMD's template emission behavior, we got a problem with the current design:

When deciding whether to "define" the struct type, we have no way of determining that we are analyzing it in the context of a return type. I think the proper fix would be to do away with the mustDefineSymbol -> emitSymbol logic in the default path for IrType construction (e.g. DtoType) and add a IrType::defineType method that would be called in places where you need to be sure to emit the type if needed (in this case, when actually defining std.file.dirEntries during std.file compilation).

This could have quite a lot of consequences all over the code base, though. I think I'll implement something like this, but only transition as much code as required for fixing this issue before the release. Later, we can clean up the situation (and might also be able to remove some of the LDC-only fields tracking template instantiation origin).

[nomad-software]

Here's a simple test case, save as file.d

    import std.stdio;
    import std.file;

    void main()
    {
            auto entries = dirEntries(".", "*", SpanMode.shallow, false);

            writeln("crashes before this compiles");
    }

Compile with: rdmd --compiler=ldc2 file.d

Error:

/tmp/.rdmd-1001/rdmd-test.d-E715299626833E7BD89AAECC25A35A6B/test.o:(.rodata._D123TypeInfo_S3std8typecons86__T10RefCountedTS3std4file15DirIteratorImplVE3std8typecons24RefCountedAutoInitialize0Z10RefCounted6__initZ[_D123TypeInfo_S3std8typecons86__T10RefCountedTS3std4file15DirIteratorImplVE3std8typecons24RefCountedAutoInitialize0Z10RefCounted6__initZ]+0x60): undefined reference to `_D3std8typecons86__T10RefCountedTS3std4file15DirIteratorImplVE3std8typecons24RefCountedAutoInitialize0Z10RefCounted10__postblitMFZv'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1

[dnadlinger]

I'm knee-deep into a rewrite of the way the symbol definition process works that will fix the issue.

The idea is to follow the DMD way of simply emitting everything in Module::members instead of trying to use mustDefineSymbol and friends (the functions are to go away entirely) to guess whether to emit the a declaration when looking at it in isolation (which isn't always possible, e.g. in the case discussed in this bug report).

Needless to say, the whole thing is a big change to the internal structure and unlikely to go without problems…