Crash: "Error: size of type <T> is not known"

[extrawurst]

This happens in ldc 0.15.1
This happens even though the same code builds fine in previous ldc and the last three dmd's

In this case: Error: size of type ImGuiCol is not known
where ImGuiCol is simply an alias int ImGuiCol.

Repository to reproduce:
https://github.com/Extrawurst/DerelictImgui

failing travis build:
https://travis-ci.org/Extrawurst/DerelictImgui/jobs/57739655

[redstar]

Confirmed. Does happen with merge-2.067, too.

[JohanEngelen]

@extrawurst Could you create a minimum test case?

[extrawurst]

currently bad timing wise.. but this lib is rather small and not complex and the failing part is in a version(LDC) block

[dnadlinger]

Unfortunately, I don't have time to investigate this myself right now, but just as a hint, in these sorts of errors forward reference issues are often involved.

[JohanEngelen]

I've tried to create a test case (using the versioned out code, etc.), but it worked for me, so... Would help getting it solved :)

[extrawurst]

@JohanEngelen I just confirmed it is still crashing:

MacBook-Air:DerelictImgui stephan$ dub test --compiler=ldc2
Generating test runner configuration '__test__library__' for 'library' (library).
Target derelict-util 1.9.1 is up to date. Use --force to rebuild.
Building derelict-imgui ~master configuration "__test__library__", build type unittest.
Running ldc2...
Unknown class of D Type!
UNREACHABLE executed at /tmp/ldc20150410-74602-ykewp5/ldc-0.15.2-beta1-src/gen/tollvm.cpp:216!
0  ldc2                     0x000000010e2e8301 llvm::sys::PrintStackTrace(__sFILE*) + 40
1  ldc2                     0x000000010e2e86ec SignalHandler(int) + 248
2  libsystem_platform.dylib 0x00007fff9c399f1a _sigtramp + 26
3  ldc2                     0x000000010e5ba0d1 nuls + 38025
4  ldc2                     0x000000010e2e8553 abort + 22
5  ldc2                     0x000000010e2d7c57 LLVMInstallFatalErrorHandler + 0
6  ldc2                     0x000000010da5dd45 DtoType(Type*) + 197
7  ldc2                     0x000000010da6778e IrFuncTyArg::IrFuncTyArg(Type*, bool, AttrBuilder const&) + 72
8  ldc2                     0x000000010da1f2ec DtoFunctionType(Type*, IrFuncTy&, Type*, Type*, bool, bool, bool) + 1912
9  ldc2                     0x000000010da6fc81 IrTypeFunction::get(Type*, Type*) + 119
10 ldc2                     0x000000010da5ddaf DtoType(Type*) + 303
11 ldc2                     0x000000010da6d080 IrTypePointer::get(Type*) + 54
12 ldc2                     0x000000010da5dd4d DtoType(Type*) + 205
13 ldc2                     0x000000010da27628 DtoResolveVariable(VarDeclaration*) + 453
14 ldc2                     0x000000010da1b3d1 CodegenVisitor::visit(VarDeclaration*) + 143
15 ldc2                     0x000000010da1a706 CodegenVisitor::visit(AttribDeclaration*) + 68
16 ldc2                     0x000000010da1a657 Declaration_codegen(Dsymbol*) + 50
17 ldc2                     0x000000010da2caa7 Module::genLLVMModule(llvm::LLVMContext&) + 669
18 ldc2                     0x000000010d91b528 main + 9013
19 libdyld.dylib            0x00007fff991855c9 start + 1
FAIL .dub/build/__test__library__-unittest-posix.osx-x86_64-ldc_0-53541FEE7851D2BC57B526F2A5E59EED/ __test__library__ executable
Error executing command test: ldc2 failed with exit code -4.

[JohanEngelen]

@extrawurst I meant I couldn't reproduce with a smaller testcase.
But I see now, indeed the library is really small. I'll try to fix it later.

[JohanEngelen]

Hmm, I've found something that looks wrong. If I have LDC output some debug info (removing the specific LDC versioned fix), I get this:

AliasDeclaration::semantic() da_ig_GetStyleColName
    alias resolved to type const(extern (C) char* function(int idx) nothrow @nogc)

the reach of const is way too much!

[JohanEngelen]

- alias da_ig_GetStyleColName             = const char*       function(ImGuiCol idx);
+ alias da_ig_GetStyleColName             = const (char)*       function(ImGuiCol idx);

fixes the compile...

[JohanEngelen]

The compiler crash happens because our stripModifiers somehow re-introduces the alias:

Logger::println("Building unstripped type: %s", t->toChars());
    t = stripModifiers( t );
Logger::println("Building stripped type: %s", t->toChars());

gives

* * * Building unstripped type: const(extern (C) char* function(int idx) nothrow @nogc)
* * * Building stripped type: extern (C) char* function(ImGuiCol idx)

[JohanEngelen]

Minimum test case:

alias ImGuiCol = int;
alias Func  = const char* function(ImGuiCol);
Func johan;

[JohanEngelen]

@extrawurst I've asked on #d, and people told me that
const( char* function(int idx) ) is the proper interpretation of
const char* function(int idx).
Because that is probably not what you want, you should modify the code to
const(char)* function(int idx).

[JohanEngelen]

Now, on to fixing LDC's stripmodifier...

[JohanEngelen]

The problem is a bug in DMD, but it is hard to track down where exactly things go out-of-sync. The problem is that for a type like const( char* function(Alias) ), with alias Alias = int, that it is resolved into a Type for which
->toChar() = "const( char* function(int) )", but
->mutableOf()->toChar() = "const( char* function(Alias) )"
So for the non-mutable type, the alias is never resolved. See PR #915

[JohanEngelen]

I don't know how to fix it. DMD is too opaque for me regarding this type business / cached types for different modifiers, etc.
See https://issues.dlang.org/show_bug.cgi?id=14500
Hoping that a DMD dev can fix it.

edit: was already fixed (accidentally it seems) in DMD HEAD

[redstar]

Thanks!!!