I think this ambiguity doesn't exist: a template value only occurs inside a template argument list, and any previous argument terminates without needing lookahead. It's either SymbolName, QualifiedName (terminating on a SymbolName), 'Z' or a type, and a type terminates with a QualifiedName at worst.

I think this has been fixed by clarifying the spec in dlang.org/#1511:

https://github.com/dlang/dlang.org/commit/6230e592c983ae742ac5ebae8db060748eb08fb8#diff-7bd92f948c3c1d8d0d16a465bb464b99L241

There's ambiguity without this distinction in the grammar.

Furthermore, if that wasn't enough, dlang.org/#1626 puts any further ambiguity to rest.

https://github.com/dlang/dlang.org/pull/1626


The binutils D demangler was implemented according to the current spec of the time 2/3 years ago, and so does the following:

---
if (ISDIGIT (*mangled))
  mangled = dlang_parse_symbol (decl, mangled);
else if (strncmp (mangled, "_D", 2) == 0)
  {
    mangled += 2;
    mangled = dlang_parse_symbol (decl, mangled);
  }
---

With the updated spec now in, I think the corrective action on my side is to separate the handling of MangleName, QualifiedName, and SymbolName into different functions, so that the above becomes:

---
if (ISDIGIT (*mangled))
  mangled = dlang_parse_symbol (decl, mangled);
else if (strncmp (mangled, "_D", 2) == 0)
  mangled = dlang_parse_mangle (decl, mangled);
---

Or maybe not, here's one symbol that fails the testsuite once I have made (some) fix-ups and removed the Pascal ambiguity check.


_D3std6traits37__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya


To break it down:
_D3std6traits37__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 MangledName -> _D QualifiedName Type

3std6traits37__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 QualifiedName -> SymbolName QualifiedName
  SymbolName -> LName
   LName -> 3 std

6traits37__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 QualifiedName -> SymbolName QualifiedName
  SymbolName -> LName
   LName -> 6 traits

37__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 QualifiedName -> SymbolName QualifiedName
  SymbolName -> TemplateInstanceName
   TemplateInstanceName -> 37 __T LName TemplateArgs Z
    LName -> 7 fqnType

TC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 TemplateArg -> T Type
  Type -> C QualifiedName

6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 QualifiedName -> SymbolName TypeFunctionNoReturn QualifiedName
  SymbolName -> LName
   LName -> 6 Object

Vbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 TypeFunctionNoReturn -> CallConvention Parameters ParamClose
  CallConvention -> V  #  <-- Pascal!!!

bi0Vbi0Vbi0Vbi0Z13addQualifiersFAyabbbbZAya
 Parameters -> Parameter Parameters
  Parameter -> Type
   Type -> bool
   Type -> int
   Type -> Found '0' # <-- bad symbol!

Or am I missing something here...

(In reply to Iain Buclaw from comment #4)
> Or am I missing something here...

I don't think I am, because the parser is in the middle of QualifiedName, and peeking the next character matches CallConvention, we can't know for sure whether this is really a TypeFunctionNoReturn or the next TemplateArg.  So backtracking is required if the first fails.

I'd like to avoid this backtracking.  Which as per first post, could either be solved by adding a stop symbol to mark the end of a QualifiedName, or Pascal should be given another identifier.

I think you are right. Any other of the TemplateArg prefixes 'S' (TypeStruct), 'H' (TypeAssocArray) and 'T' (TypeTypedef) should be affected aswell.

There is also an accuracy in the grammar still. The actual implementation for TemplateArgX is

TemplateArgX:
    'T' Type
  | 'V' Type Value
  | 'S' Number QualifiedName
  | 'S' Number MangledName
  ;

where Number is the length of the full name.
MangledName includes C,C++ and pragma(mangle) manglings.
Number QualifiedName causes two concatenated Numbers, Issue 3043.

> Any other of the TemplateArg prefixes 'S' (TypeStruct), 'H' (TypeAssocArray) and 'T' (TypeTypedef) should be affected aswell.

Probably not, as the rule above avoids trouble with symbol aliases, and types only contain QualifiedName which only contain function types.

(In reply to Rainer Schuetze from comment #8)
> > Any other of the TemplateArg prefixes 'S' (TypeStruct), 'H' (TypeAssocArray) and 'T' (TypeTypedef) should be affected aswell.
> 
> Probably not, as the rule above avoids trouble with symbol aliases, and
> types only contain QualifiedName which only contain function types.

Yeah, I think I would have spotted it otherwise.

I think all I can do on my side is have a boolean function that attempts to parse TypeFunctionNoReturn and returns true only if a digit immediately follows (have matched the next QualifiedName in the grammar rule).

It means in the worst case I'm going over the section of the symbol twice, but at least I don't have a special case for Pascal.  :-(

https://github.com/dlang/dmd/pull/6702
https://github.com/dlang/druntime/pull/1812
https://github.com/dlang/phobos/pull/5333

I'm going to drop this down to Normal, as the implementation on my side is now "satisfactory" granted now that handlers for MangledName and QualifiedName have been split into two separate routines.

Still this should be kept open on the more wider basis that this prevents the mangling grammar from being context-free.

Here's a symbol from the phobos unittests that hits this ambiguity and is pretty difficult to demangle, even with backtracking:

_D3std8typecons118__T8NullableTC3std8typecons19__unittestL3090_156FZ12TestToStringVC3std8typecons19__unittestL3090_156FZ12TestToStringnZ8Nullable6__initZ

extern(Pascal) is deprecated, not worth fixing.