Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Issue 11192 - std.demangle doesn't demangle alias template arguments #906

Merged
merged 1 commit into from
Aug 7, 2014

Conversation

sinkuu
Copy link
Contributor

@sinkuu sinkuu commented Jul 21, 2014

https://issues.dlang.org/show_bug.cgi?id=11192

Support demangling of alias template arguments.

@complexmath
Copy link
Member

There is already a parseMangledName function. Is it possible to use that instead of re-implementing it in the switch case?

@sinkuu
Copy link
Contributor Author

sinkuu commented Jul 28, 2014

OK, done.

@complexmath
Copy link
Member

Thanks. Something still doesn't really sit well with me regarding this fix. I don't like that the ABI now has two conditions with the same prefix. That indicates an ambiguity, and while there are others, I want to check into this a bit more. I'm hoping we can always just call parseMangledName here have that take care of both cases. And either way, the ABI will have to be corrected.

@complexmath
Copy link
Member

Okay, yep this is ambiguous. Both start with a Number, then in the LName case alphanumeric characters (which allows "_D"), and in the MangledName case "_D" followed by a Number, etc. I guess we have to do as you've done here and just assume that anything starting with "_D" is a MangledName, but I'd like to call out the ambiguity in the code if possible. Suggestions forthcoming.

@rainers
Copy link
Member

rainers commented Jul 29, 2014

Emitting "_D" for alias template arguments looks like a compiler bug. It isn't mentioned by the ABI http://dlang.org/abi.html.

@sinkuu
Copy link
Contributor Author

sinkuu commented Jul 29, 2014

I found this issue page: Issue 5957 - Ambiguous mangling of module and template in template symbol args
Should there be ABI changes?

@complexmath
Copy link
Member

There are a bunch of ambiguities. In fact, templates in general are ambiguous (see mayBeTemplateInstanceName). They should all be fixed, and probably all at once, since it will break binary compatibility with existing compiled code.

@complexmath
Copy link
Member

Here's what I'm thinking:

http://www.invisibleduck.org/sean/tmp/11192.patch

Then it's pretty obvious in code that there's an ambiguity and if for some reason the symbol is a qualifiedName starting with "_D" then it should recover and handle that instead (though it's worth a test case).

@sinkuu
Copy link
Contributor Author

sinkuu commented Jul 30, 2014

Thanks, updated.

@quickfur
Copy link
Member

quickfur commented Aug 5, 2014

See also: #725

@complexmath
Copy link
Member

In general, I think demangle should properly demangle all symbols generated by the compiler. Then if there are issues where the mangling seems wrong for some reason, a bug should be filed against DMD. When that is fixed, the change can be removed from demangle. The only exception is particularly egregious mangling issues for which there isn't a clean solution in demangle, but I haven't encountered any of these yet. In short, I think this change should be merged and then a bug filed.

@quickfur
Copy link
Member

quickfur commented Aug 6, 2014

Agreed, we should demangle all symbols produced by the compiler. Not doing so is frustrating when you're trying to use a debugger. (Or debug a stacktrace, disassemble an executable, etc..)

complexmath added a commit that referenced this pull request Aug 7, 2014
Issue 11192 - std.demangle doesn't demangle alias template arguments
@complexmath complexmath merged commit 5eb5aac into dlang:master Aug 7, 2014
@sinkuu sinkuu mentioned this pull request Aug 17, 2014
@sinkuu sinkuu deleted the fix_demangle_alias branch September 7, 2014 12:36
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants