fix Issue 9466 - Compiler crash with code-coverage generation with large files

[WalterBright]

valgrind once again found the problem.

https://d.puremagic.com/issues/show_bug.cgi?id=9466

[ghost]

Huh.. what kind of strange file name in the diagnostic is this? And why is this related to the COV fixes?

[WalterBright]

The -cov error was caused by a string mixin. The string had more lines in it than the source file, and so there was memory corruption.

The problem is that string literals can contain an arbitrary number of lines, and those lines may have no correspondence to any source file. So what to do, what to do, to give them source/line info? My solution was to create a pseudo-filename that consisted of the source location where the mixin statement was.

[ghost]

This will definitely break tools however. Tools which actively support D might be fixable so they take this change into account, but most text-based tools which e.g. allow go-to-file+line by double-clicking a diagnostic message will not work for string mixins anymore.

[MartinNowak]

But that never worked correctly, right?
Note that this pull is related to #426 which fixes debugging for mixins.

[ghost]

Well, broken but at least we could jump to a file. I do like #426 though.

[MartinNowak]

The error message should say, in a mixin and then point to the mixin location. Likewise cov and debug lines should all be pointing to the single line with the mixin.

[yebblies]

With this change, I now get a crash in optlink when linking ddmd.

[yebblies]

When compiling with -g or -gc, that is.

[yebblies]

Reduced:

string gen()
{
    string m;
    foreach(i; 0..2048)
        m ~= "mixin(\"assert(0);\");\n";
    return m;
}

void main()
{
    mixin(gen());
}

The generate loop is just to reduce the size of the test case, the expanded version with 2048 lines of mixin works just fine. Looks hitting an internal module count limit inside optlink.

This will need to be reverted if optlink can't be fixed soon.

https://d.puremagic.com/issues/show_bug.cgi?id=11559