[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2020-06-07 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17379

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #9 from Steven Schveighoffer  ---
I'm OK closing it. The only reason (I think) I reopened is because technically,
simplifying the mangling can still reduce further the symbol names. So even
though this is not a critical problem any more, there is still some juice that
could potentially be squeezed out of this.

On the other hand, putting the type in the template space instead of inside the
function achieves the same thing, so maybe it's not important enough to deal
with this.

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2020-06-07 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17379

Mathias LANG  changed:

   What|Removed |Added

 CC||pro.mathias.l...@gmail.com

--- Comment #8 from Mathias LANG  ---
I think we should close this. This issue title is about a solution rather than
a problem. As you mentioned Steven, the underlying issue is mitigated by the
backreference mangling, which is the "correct" solution IMO. Any lowering /
rewrite invoke a risk of conflict / need for support in other tools (e.g.
debugger), so it's just shifting the problem.

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #7 from Steven Schveighoffer  ---
Reopening, in case someone wishes to tackle this issue with the hairy problems
it has.

The largest blocking issue to getting this to work is if you have 2 overloads
of the same function template (this is completely made up, but something
similar would cause problems):

auto foo(T)(T t, int x)
{
   static struct Result {T t; int x;}
   return Result(t, x);
}

auto foo(T)(T t, string x)
{
  static struct Result {T t; string x;}
  return Result(t, x);
}

If you refactor this, then the Result struct doesn't get properly mangled -- it
only depends on the template itself. This will produce 2 identical manglings
for the 2 functions.

Note that if you do actually do the refactoring here (move the Result outside
the function), the current compiler simply doesn't redefine the Result struct
-- it considers it fully defined in the first overload.

So a user would not refactor both, he would get errors on his compilation. But
the compiler that was just adjusting the mangling would cause other problems.

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

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

ZombineDev  changed:

   What|Removed |Added

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

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15831
 Resolution|--- |WONTFIX

--- Comment #6 from Steven Schveighoffer  ---
I think actually, we can close this, as Rainer's fix for issue (in the latest
version of the compiler) mitigates the need for this.

There are also ambiguity problems when there are function overloads.

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

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

Walter Bright  changed:

   What|Removed |Added

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

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

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

--- Comment #5 from Georgi D  ---
(In reply to Rainer Schuetze from comment #4)
> > I am not sure what you mean by prepend the function name. The suggestion 
> > does not prepend the function name. Could you elaborate?
> 
> I meant that the demangler has to prepend the function name (including
> arguments to disambiguate overloads) to the identifier to print out the full
> name (if the demangled name is supposed not to show the transformation). 
> 
> > This is not meant as a special case rule. ... It is also not ambiguous 
> > since the transformation is equivalent to explicitly writing out the 
> > template.
> 
> Consider similar structs defined elsewhere, e.g. in nested or chained
> functions:
> 
> template foo(T)
> {
>static struct Result
>{
>   int x;
>}
> 
>auto fun(T t)
>{
>   static struct Result
>   {
>  T t;
>   }
>   return Result(t);
>}
> 
>auto foo(T t)
>{
>   return fun(t);
>}
> }
> 
> What is the mangling of the return type of foo?

Yes, I did consider this case and in this sense the suggestion is for the case
where there is only one entry in the template.

The position where I started this from is:

1) regardless of how good a compression is a shorter input will generate a
shorter output. Especially if the patterns are similar.
2) looking at the chain() method in std there is an equivalent transformation
which produces shorter symbol names by taking the voldemort type outside of the
method.
3) my first impulse was to create a pull request for phobos and make the
trasformation as a code change
4) following the path of 3) though would have meant removing all voldemort
types from phobos and in effect discouraging them in template code.
5) since I did not like 4) I considered the option of the compiler making the
transformation without the need of a code change.

The feature can be made more generic if we use a generated name for the
voldemort types which are not supposed to be visible except by the compiler
anyway.

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2017-05-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17379

--- Comment #4 from Rainer Schuetze  ---
> I am not sure what you mean by prepend the function name. The suggestion 
> does not prepend the function name. Could you elaborate?

I meant that the demangler has to prepend the function name (including
arguments to disambiguate overloads) to the identifier to print out the full
name (if the demangled name is supposed not to show the transformation). 

> This is not meant as a special case rule. ... It is also not ambiguous since 
> the transformation is equivalent to explicitly writing out the template.

Consider similar structs defined elsewhere, e.g. in nested or chained
functions:

template foo(T)
{
   static struct Result
   {
  int x;
   }

   auto fun(T t)
   {
  static struct Result
  {
 T t;
  }
  return Result(t);
   }

   auto foo(T t)
   {
  return fun(t);
   }
}

What is the mangling of the return type of foo?

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2017-05-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17379

--- Comment #3 from Georgi D  ---
(In reply to Rainer Schuetze from comment #2)
> Is this meant as a special rule "if the symbol has only a single identifier,
> prepend the function name and signature"? This could work but only helps for
> some cases. 
> 

I am not sure what you mean by prepend the function name. The suggestion does
not prepend the function name. Could you elaborate?

> Otherwise it easily gets ambiguous and I'd rather see a special token for
> "unspecified return type" that could be demangled as "auto".
> 
> See https://github.com/dlang/dmd/pull/5855 for a more generic approach.

This is not meant as a special case rule. It is a generic lowering of voldemort
types in function templates to be as if defined outside of the function so they
do not grow exponentially in size. It does not have a limit on the number of
template arguments. It is also not ambiguous since the transformation is
equivalent to explicitly writing out the template.

I am aware of https://github.com/dlang/dmd/pull/5855 and think it is a great
idea but it is a compression of the symbol so if the original symbol is shorter
then the compressed symbol is also going to be shorter. This suggestion tackles
the problem of how the original symbol can be shorter.

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2017-05-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17379

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Schuetze  ---
Is this meant as a special rule "if the symbol has only a single identifier,
prepend the function name and signature"? This could work but only helps for
some cases. 

Otherwise it easily gets ambiguous and I'd rather see a special token for
"unspecified return type" that could be demangled as "auto".

See https://github.com/dlang/dmd/pull/5855 for a more generic approach.

--


[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2017-05-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17379

--- Comment #1 from Georgi D  ---
I discussed this is Andrey and Walter at D-Conf 2017 and the overall agreement
is that it makes sense to change the mangling of voldemort types this way.

For the example above the mangled name changes like this:

- _D4test10__T3fooTiZ3fooFNaNbNiNfiZS4test10__T3fooTiZ3fooFiZ6Result
+ _D4test10__T3fooTiZ3fooFNaNbNiNfiZS4test10__T3fooTiZ6Result

--