[WIP] Windows: Fix wrongly caught exceptions due to non-unique TypeInfo_Class names

[kinke]

WinEH depends on string comparisons to check for matching catch clauses, and currently depends on TypeInfo_Class.name to generate these strings at runtime when throwing an exception, see
https://github.com/ldc-developers/druntime/blob/19731a92a97dbe4d7f7a4e15ceaff8444a1f879a/src/ldc/eh_msvc.d#L192-L211.
So if those names were fully qualified (cd->toPrettyChars(*true*) during ClassInfo generation), we'd be fine, but that'd obviously be a breaking change and diverge from upstream.

[kinke]

@Geod24: This caused it: https://github.com/Geod24/localrest/blob/5196f35edbc2a5ab83573665fb9f789217477c85/source/geod24/LocalRest.d#L529. You may want to extract it as a private module-level class to prevent needless 'duplicates' (nested in templated RemoteAPI class and templated spawned function).

[JohanEngelen]

hm, do you want to ask the mailinglist if this is really intended behavior?

[kinke]

I surely don't want to.

[JohanEngelen]

I think I misunderstood.
I thought this code would catch the exception (exceptions get same name), but it doesn't on Linux. So that's good. Is this working differently on Windows?

import std.stdio;

struct Foo(T) {
    // name: gh3501.foo!(S).foo.MyException
    static class MyException : Exception
    {
        this() { super(null); }
    }
}

void bar1() {
    struct S {}
    Foo!S f;
    throw new f.MyException();
}

void bar2() {
    struct S {}
    Foo!S f2;
    try  {
        bar1();
    }
    catch (f2.MyException e)  {
        writeln("Exception caught");
    }
}

void main() {
 	bar2();   
}

[kinke]

This is purely Windows specific (edit: and LDC-specific, works with DMD), and yes, the exception gets wrongly caught. - I'm not sure what the underlying requirement for the string comparison is, but I guess it's the used Microsoft VC++ personality function. We could theoretically work around it in the compiler, but it'd probably be a big PITA (as the whole different MSVC EH universe wrt. LLVM IR altogether).

[Geod24]

You may want to extract it as a private module-level class to prevent needless 'duplicates' (nested in templated RemoteAPI class and templated spawned function).

Thanks for the pointer! Indeed I'm going to go with that solution, since we want to support a range of compilers.

[kinke]

[I didn't mention this to work around this particular issue for LDC, but because of template bloat, compilation speed etc.]

[JohanEngelen]

This is purely Windows specific (edit: and LDC-specific, works with DMD), and yes, the exception gets wrongly caught.

If LDC behavior deviates from DMD in this case, I think we should mention this in the release notes as a known issue.
Moreso because programs will behave differently on Linux than on Windows.
Do you agree?

[kinke]

Well we should probably start by adding an LDC issue for this (I previously thought this wouldn't be a real issue in practice, but your example shows that it can indeed be). ;)

[kinke]

I've pushed a fix, at the cost of an extra slice (mangledName) for all ClassInfos and MSVC targets, only populated for Throwable and derived classes.

[rainers]

I guess a similar problem will appear upstream if dlang/druntime#2874 is merged, but the issue has already appeared for other types: dlang/druntime#3138. So I think fixing the name generation would be better.

[kinke]

I agree, but that's not something we can easily switch to here. Once it's fixed upstream, we can get rid of this workaround here.

[kinke]

Update: we've come up with a feasible approach upstream, see PR linked above. It's 'blocked' by the poor way to tackle tight compiler/druntime couplings upstream, probably requiring 4 PRs in total (2x DMD, 2x druntime) and more work just to handle the transitions.

[kinke]

Superseded by fully qualified (and hence unique) TypeInfo_Class names since D v2.098 and according adaptations in #3821.