Partial Fix Issue 8578 - Demangle special symbols (__init, __Class, etc....

[Poita]

Mostly fixes Issue 8578. The last case still contains mangled text, but the first four are fixed.

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

[ghost]

@9rnsr @yebblies LGTY? I'm not familiar with mangling.

[yebblies]

I think it should probably have a list of the symbols that are special-cased. You can find them by grepping the compiler source for calls to toSymbolX.

[9rnsr]

I don't think that demangling these special symbols is correct. Although they looks like D mangled symbols, they are not correct D language symbols.

That's similar to C++ mangled symbols. core.demangle does not support C++ mangling scheme. Likewise, I think it should not support the symbols that not follow the D mangling scheme.

[Poita]

@9rnsr I see your point, but these are mangled symbols produced only by D programming language compilers. As a practical matter, users of D will want to demangle these symbols, and if D library demanglers can't demangle them, then who will?

[9rnsr]

if D library demanglers can't demangle them, then who will?

No one. They are not D symbols, so they have no demangle names. I think we should follow the principle.

[rainers]

I wonder why these have special mangling to start with. I think that should be changed in the compiler, using double-underscore prefixed names is enough to mark them "special".

[9rnsr]

Because to prevent conflict with normal D symbols.

Note that, the special symbols should reflect D's module scope - for example, the TypeInfo symbols for struct S in mod1 and struct S in mod2 should have different names. Therefore the mangled name looks similar to normal D symbols (_D16TypeInfo_4mod11S6__initZ and _D16TypeInfo_4mod21S6__initZ). But they are still special and does not follow the normal mangling scheme.

[yebblies]

I don't think that demangling these special symbols is correct. Although they looks like D mangled symbols, they are not correct D language symbols.

Why? If a user is seeing them in an error message, we might as well demangle them into a more human-friendly form. Isn't that the whole point of demangle?

[ghost]

At the very least they should be demangled in stack traces.

[yebblies]

At the very least they should be demangled in stack traces.

None of these appear in stack traces, they are typinfo/classinfo/vtbl etc

[ghost]

None of these appear in stack traces, they are typinfo/classinfo/vtbl etc

Although I guess they could appear in linker errors? In that case a tool like RDMD could use demangle for prettier output (at least w.r.t. Optlink, Unilink at least does the proper thing and demangles everything for you).

[yebblies]

Although I guess they could appear in linker errors?

Yep, all the time.

[rainers]

Note that, the special symbols should reflect D's module scope - for example, the TypeInfo symbols for struct S in mod1 and struct S in mod2 should have different names. Therefore the mangled name looks similar to normal D symbols (_D16TypeInfo_4mod11S6__initZ and _D16TypeInfo_4mod21S6__initZ). But they are still special and does not follow the normal mangling scheme.

I'm not sure I can follow. The mangling of static struct members preserves module info aswell. They could mangle just as that, the double underscore marks them as "special", very much like __ctor, __modtest, __unittest and others.

[MartinNowak]

We should make those symbols compliant to http://dlang.org/abi.html, either by chaging the ABI specs or the compiler. The simplest fix would be to reserve a mangling type for compiler/runtime internal data.

[andralex]

@MartinNowak I assigned this to you :)

[MartinNowak]

Can't we just augment the mangling rules to say that the type 'Z' is for compiler internal symbols?

[quickfur]

I don't agree that we should not demangle these. The current situation makes debugging very difficult because these symbols are referenced all over the place, but unless you can demangle D symbols in your head, they are basically unreadable (ddemangle does not demangle them). If they don't follow current mangling rules, then we should either make them follow the rules, or we should change the rules to include them as special cases. I don't agree that people should be expected to know compiler internals just to be able to tell, for example, that a module constructor is being referenced, that's just an artificial unnecessary barrier to debugging.

[quickfur]

ping

[Poita]

I'll see if I can add these to the spec and rebase.

[Poita]

Rebased and updated to list symbols.

ABI spec udpate here: dlang/dlang.org#628

[quickfur]

LGTM. Let's do this. The D demangler really needs to be able to deal with these symbols.

[MartinNowak]

Auto-merge toggled on

[Orvid]

This reminds me, I should get around to modifying the original demangler to not use exceptions to parse, unless someone else wants to?

[rainers]

This reminds me, I should get around to modifying the original demangler to not use exceptions to parse, unless someone else wants to?

That would be great. I always thought it to be very bad to use exceptions within the exception handler. The win32 druntime unittest usually crash for me if I don't run cv2pdb on it, and I suspect it is caused by this.

[MartinNowak]

This reminds me, I should get around to modifying the original demangler to not use exceptions to parse, unless someone else wants to?

That would be highly appreciated.

[complexmath]

Exceptions are only thrown on a buffer overrun, which isn't an expected occurrence. Is this really necessary?

[complexmath]

To elaborate, it should be possible to use demangle anywhere in D, and so from the outset I'd basically intended it to be @nogc, except that attribute didn't exist. It may be worth having two overloads to demangle--one where an output buffer is supplied and another where one is not. The one without would catch and reallocate and the other would return an error on buffer overrun. I absolutely don't want the code to be growing the buffer as needed as writes occur.