Check unnecessary vtbl emissions

[redstar]

Reported by temtaine in news group (http://forum.dlang.org/post/yephpwnmvkcpyjnpbzti@forum.dlang.org). Look at the following modules:

A.d

import B;

B.d

import C;
import D;

import std.range;

class Font {
public:
    mixin RCounted;

    auto makeTextData(string s) {
        // split text by spaces
        auto arr = s.splitter.array;
    }    
}

class Engine {
    RC!Font font;
}

C.d

import A;

D.d

template RCounted() {
        void release() { this.destroy; }
}

struct RC(T) {
    ~this() {  _rc_ptr.release; }
    T _rc_ptr;
}

ldc2 -c A.d B.d C.d D.d works but ldc2 -c A.d produces an error message.

[ckamm]

Notes so far: The failure happens in DtoDefineFunction() for std.array.Appender!(string[]).Appender.Data.__xopEquals because semantic3 is never run for it (not even while gagged).

DMD does not call toObjFile on this FuncDeclaration at all and doesn't semantic3 it either. It does not even call toObjFile on the TemplateInstance Appender!(string[]). For that TemplateInstance not even semantic() is run.

The next step would be to figure out why we run TemplateInstance::semantic() for Appender!(string[]).

[redstar]

I played a bit with the error message. DtoDefineFunction() is called for every method of std.array.Appender - with no semantic3 run.

[ckamm]

When we codegen object.destroy!(Font) (dmd does this too), we call IrTypeClass:get() for B.Font and that generates the vtbl for that class (I don't think dmd does that). To get the vtbl we call semantic3 on all members (makeTextData in the test case) and that generates the Appender!(string[]) template instance but doesn't semantic3 it.

We either need to ensure we semantic3 the template instances generated during our calls back into the frontend for vtbl generation - or make sure we don't emit it in the first place.

[dnadlinger]

I think we should just try to not emit the vtbl at all, unless there is a compelling use case as to why not doing so is a bug in DMD. Even then, we should probably try to fix this upstream.

[kinke]

The original symptoms should be worked around by #1709.

When we codegen object.destroy!(Font) (dmd does this too), we call IrTypeClass:get() for B.Font and that generates the vtbl for that class (I don't think dmd does that).

Still needs to be looked into.

[kinke]

Vtables are emitted once into the CU owning the class declaration. They are needed for the class init symbol, which is also emitted in that CU, so definitely not superfluous.

The testcase (nowadays requiring import std.algorithm, std.array;) works with LDC v1.27.