Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 09, 2015 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 Andrei Alexandrescu <andrei@erdani.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|D1 & D2 |D2 -- |
April 11, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 Rainer Schuetze <r.sagitario@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.sagitario@gmx.de --- Comment #1 from Rainer Schuetze <r.sagitario@gmx.de> --- 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. -- |
April 12, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |ibuclaw@gdcproject.org --- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> --- 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); --- -- |
April 12, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 --- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> --- 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! -- |
April 12, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 --- Comment #4 from Iain Buclaw <ibuclaw@gdcproject.org> --- Or am I missing something here... -- |
April 12, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 --- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> --- (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. -- |
April 12, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 --- Comment #6 from Rainer Schuetze <r.sagitario@gmx.de> --- I think you are right. Any other of the TemplateArg prefixes 'S' (TypeStruct), 'H' (TypeAssocArray) and 'T' (TypeTypedef) should be affected aswell. -- |
April 12, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 --- Comment #7 from Rainer Schuetze <r.sagitario@gmx.de> --- 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. -- |
April 12, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 --- Comment #8 from Rainer Schuetze <r.sagitario@gmx.de> --- > 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. -- |
April 14, 2017 [Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=14591 --- Comment #9 from Iain Buclaw <ibuclaw@gdcproject.org> --- (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. :-( -- |
Copyright © 1999-2021 by the D Language Foundation