Bug 11720 – Function-local static variables should cause "already defined in another scope" error

Status
RESOLVED
Resolution
DUPLICATE
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-12-10T16:55:00Z
Last change time
2015-07-27T13:16:15Z
Keywords
pull, wrong-code
Assigned to
nobody
Creator
timothee.cour2

Comments

Comment #0 by timothee.cour2 — 2013-12-10T16:55:31Z
import std.stdio; void main(){ struct A{ int x; int x2; } A a; fun(a); } void fun(T)(T a){ foreach(i, member; a.tupleof) { static temp=a.tupleof[i].stringof; string name = a.tupleof[i].stringof[2..$]; writeln(i," ",temp," ",name);//prints 0 a.x x then 1 a.x x2 assert(name==temp[2..$]);//fails } }
Comment #1 by k.hara.pg — 2013-12-10T18:19:25Z
This is unrelated bug to tupleof property. compile-time iterated foerach loop is unrolled to multiple scope statements. foreach (T; TypeTuple!(int, double)) { static temp = T.stringof; } // is equivalent to: { static temp = int.stringof; } { static temp = double.stringof; } Then, two static temp variables have exactly same mangled name, so they conflicts and should cause linker error at least. However, all of instantiated code will be placed in COMDAT section, so they incorrectly share the storage. Changed the summary.
Comment #2 by k.hara.pg — 2013-12-10T18:24:47Z
Comment #3 by blah38621 — 2013-12-10T19:44:01Z
(In reply to comment #2) > https://github.com/D-Programming-Language/dmd/pull/2947 Is having it error really the right way to fix this? It looks to me to be an issue with the fact that the bodies of a statically expanded foreach are not specially mangled.
Comment #4 by k.hara.pg — 2013-12-10T20:29:10Z
(In reply to comment #3) > (In reply to comment #2) > > https://github.com/D-Programming-Language/dmd/pull/2947 > > Is having it error really the right way to fix this? It looks to me to be an > issue with the fact that the bodies of a statically expanded foreach are not > specially mangled. Yes. In D, function local declarations which are assigned to global symbols cannot have same name because of the mangled name conflict. void main() { { void f() {} } { void f() {} } // Error: declaration f is already defined in another scope in main { struct S {} } { struct S {} } // Error: declaration S is already defined in another scope in main { static int v = 1; } { static int v = 1; } // should be same error }
Comment #5 by samukha — 2013-12-11T02:48:29Z
Looks like a design mistake.
Comment #6 by samukha — 2013-12-11T03:42:16Z
(In reply to comment #5) > Looks like a design mistake. FWIW, C++ seems to do a sane thing. Class decls do not conflict and the assertion passes: int main(int argc, char *argv[]) { int *x1; int *x2; { class C { }; static int x; x1 = &x; } { class C { }; static int x; x2 = &x; } assert(x1 != x2); }
Comment #7 by blah38621 — 2013-12-11T07:16:12Z
While yes I would agree that: { static int v = 1; } { static int v = 1; } Should be an error, and thus the PR should be merged. I don't agree that the reason this issue was created: foreach (T; TypeTuple!(int, double)) { static temp = T.stringof; } should be an error, sorry if I failed to explain myself well enough originally.
Comment #8 by github-bugzilla — 2013-12-25T14:45:12Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0b575f80b644715207ff18ca92d7bfb4708186aa fix Issue 11720 - Function-local static variables should cause "already defined in another scope" error https://github.com/D-Programming-Language/dmd/commit/5901e163e48a5f13a5a1d970741229b3c2878e0d Merge pull request #2947 from 9rnsr/fix11720 Issue 11720 - Function-local static variables should cause "already defined in another scope" error
Comment #9 by andrej.mitrovich — 2014-01-30T03:39:14Z
Mark as fixed? As for avoiding mangling issues, I think this is Issue 3031.
Comment #10 by k.hara.pg — 2015-07-27T13:16:15Z
(In reply to Andrej Mitrovic from comment #9) > As for avoiding mangling issues, I think this is Issue 3031. Mark as a duplication of 3031. *** This issue has been marked as a duplicate of issue 3031 ***