Re: Ambiguous mangling of symbols declared in nested scopes
H. S. Teoh via Digitalmars-d wrote in message news:mailman.4366.1405642929.2907.digitalmar...@puremagic.com... Hmm. How to generate a unique id? It must be module-wide, but not program-wide, because otherwise you get a different mangling depending on the order of imports. It must not increment within the same scope: An easy option is to just have a counter inside the enclosing fd and increment it each time a local is created. In D I'd do it with an int[string] to track each name independently, but it's probably not worth the trouble in C++. These mangled names are not externally visible and do not need to be stable, just unique.
Re: Ambiguous mangling of symbols declared in nested scopes
H. S. Teoh via Digitalmars-d wrote in message news:mailman.4230.1405534833.2907.digitalmar...@puremagic.com... But maybe some of the DMD experts can speak up about this. ;-) This is fairly well known, the same thing exists for static variables and nested functions etc. I think there is even a bounty on one of those bugs. The solution is also fairly straightforward - give each local declaration a unique name (for mangling only). It probably requires some minor structural changes in dmd.
Re: Ambiguous mangling of symbols declared in nested scopes
Slight correction : it is not a mangling of variable that is a problem (local variables don't have any mangling) but mangling of the function itself (it naively uses variable name for mangled name generation). Should use something like unique id instead.
Re: Ambiguous mangling of symbols declared in nested scopes
On Thursday, 17 July 2014 at 10:03:08 UTC, Daniel Murphy wrote: The solution is also fairly straightforward - give each local declaration a unique name (for mangling only). It probably requires some minor structural changes in dmd. As an aside, these names should be independent of import/instantiation order for things like forceinline to work properly (see https://github.com/jerro/ldc/compare/inlining, last commit). David
Re: Ambiguous mangling of symbols declared in nested scopes
I opened a number of bugs regarding ambiguities while writing core.demangle. They're all tagged with some searchable keyword too, though I can't recall what it is.
Re: Ambiguous mangling of symbols declared in nested scopes
On Thu, Jul 17, 2014 at 10:15:56AM +, Dicebot via Digitalmars-d wrote:
Slight correction : it is not a mangling of variable that is a problem
(local variables don't have any mangling) but mangling of the function
itself (it naively uses variable name for mangled name generation).
Should use something like unique id instead.
Hmm. How to generate a unique id? It must be module-wide, but not
program-wide, because otherwise you get a different mangling depending
on the order of imports. It must not increment within the same scope:
void myFunc(alias A)() { ... }
void main() {
{
int i;
// All 3 instances below should refer to the
// same instantiation of myFunc.
myFunc!i();
myFunc!i();
myFunc!i();
}
{
int i, j;
myFunc!i(); // but this one should be different
{
myFunc!i(); // this one should be same as
previous line
myFunc!j(); // this one should be different
}
myFunc!j(); // same as previous line
}
Also, it should resolve ambiguities between identically-named inner
functions declared in nested scopes:
void delegate() dg, dg2;
{
void inner() { ... }
myFunc!inner();
myFunc!inner(); // same as previous line
dg = inner;
}
{
void inner() { ... }
myFunc!inner(); // different from previous scope
dg2 = inner;
}
assert(dg !is dg2);
}
So looks like we need to index scopes inside function bodies, perhaps by
number of scopes in preceding lexical position, and any inner function's
mangled name should somehow incorporate this index. Alias parameters
should also incorporate this index in the mangling of the resulting
template.
T
--
It only takes one twig to burn down a forest.
Re: Ambiguous mangling of symbols declared in nested scopes
Something like reduced hash from mangled name of parent scope + incremental ID for each new stack instance.
Re: Ambiguous mangling of symbols declared in nested scopes
On Wednesday, 16 July 2014 at 17:24:27 UTC, H. S. Teoh via Digitalmars-d wrote: Today I was investigating this bug: https://issues.dlang.org/show_bug.cgi?id=10619 and found that the problem appears to be an ambiguous mangling of local variables declared in nested scopes. ... Amazing how such a bug survived until now! Can all (meaningful) scopes of a module be numbered internally to distinguish them? Some way, like lambdas are. Or is it too much of a change? If they can, the scope's unique ID can then go into the mangled name. Ivan Kazmenko.
Re: Ambiguous mangling of symbols declared in nested scopes
On Wed, Jul 16, 2014 at 05:36:45PM +, Ivan Kazmenko via Digitalmars-d wrote: On Wednesday, 16 July 2014 at 17:24:27 UTC, H. S. Teoh via Digitalmars-d wrote: Today I was investigating this bug: https://issues.dlang.org/show_bug.cgi?id=10619 and found that the problem appears to be an ambiguous mangling of local variables declared in nested scopes. ... Amazing how such a bug survived until now! Well, I found out about it last year and filed a bug, but it seems to have escaped everyone's attention. Prior to that, a friend of mine who occasionally dabbles in D has seen the problem, I don't know how long ago. It makes me wonder if others may have seen it too, but only haven't spoken up about it. :-/ In any case, I've been wanting to familiarize myself more with dmd code, so this is as good an opportunity as any other. Plus, I'm tired of waiting around for somebody more familiar with dmd to take notice, so I decided that I'm gonna do something about it myself, even if it means taking longer 'cos right now I've no idea what I'm doing. :-P Can all (meaningful) scopes of a module be numbered internally to distinguish them? Some way, like lambdas are. Or is it too much of a change? If they can, the scope's unique ID can then go into the mangled name. [...] Ultimately we'll have to do something like that, I think, since I can't think of any other way to disambiguate between all these local variables. But maybe some of the DMD experts can speak up about this. ;-) T -- Freedom: (n.) Man's self-given right to be enslaved by his own depravity.
