[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2020-08-21 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

Basile-z  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |WONTFIX

--- Comment #13 from Basile-z  ---
extern(Pascal) is deprecated, not worth fixing.

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

Walter Bright  changed:

   What|Removed |Added

   Keywords||mangling
 CC||bugzi...@digitalmars.com

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-06-03 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-06-02 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #12 from Rainer Schuetze  ---
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

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-15 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

Iain Buclaw  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #11 from Iain Buclaw  ---
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.

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-15 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #10 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/6702
https://github.com/dlang/druntime/pull/1812
https://github.com/dlang/phobos/pull/5333

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #9 from Iain Buclaw  ---
(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.  :-(

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #8 from Rainer Schuetze  ---
> 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.

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #7 from Rainer Schuetze  ---
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.

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #6 from Rainer Schuetze  ---
I think you are right. Any other of the TemplateArg prefixes 'S' (TypeStruct),
'H' (TypeAssocArray) and 'T' (TypeTypedef) should be affected aswell.

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #5 from Iain Buclaw  ---
(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.

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #4 from Iain Buclaw  ---
Or am I missing something here...

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

--- Comment #3 from Iain Buclaw  ---
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__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyaZAya


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

3std6traits37__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyaZAya
 QualifiedName -> SymbolName QualifiedName
  SymbolName -> LName
   LName -> 3 std

6traits37__T7fqnTypeTC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyaZAya
 QualifiedName -> SymbolName QualifiedName
  SymbolName -> LName
   LName -> 6 traits

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

TC6ObjectVbi0Vbi0Vbi0Vbi0Z13addQualifiersFAyaZAya
 TemplateArg -> T Type
  Type -> C QualifiedName

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

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

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

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

Iain Buclaw  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ibuc...@gdcproject.org

--- Comment #2 from Iain Buclaw  ---
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);
---

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-04-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
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.

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2015-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14591

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|D1  D2 |D2

--