http://d.puremagic.com/issues/show_bug.cgi?id=1894
Don changed:
What|Removed |Added
OS/Version|Linux |All
Severity|normal |blocker
--- Comment #3 from Don 2009-09-16 11:48:04 PDT ---
This is one example of an endemic problem. There's a host of possible test
cases which fail. Basically, OnScopeStatement works ONLY when it is in a
CompoundStatement: it's the only time when scopecode() is called. Everywhere
else, the only thing called is OnScopeStatement::semantic(), which does
nothing.
I think that what should happen, is that since in these cases it's the only
thing in its scope, OnScopeStatement::semantic should either (1) generate an
error; or (2) run semantic on its statement (depending on the type of scopecode
it is).
And labels (bugzilla 1087) should be treated specially, since they are not
really statements themselves.
Here's a non-exhaustive collection of test cases, each of which generate two
asm instructions so that the disassembly is very easy to understand. In each
case, an 'int 3' instruction should appear, but none are present.
This blocks deterministic destruction.
(BTW in each of these cases, in D2, if you replace "scope(exit) asm{int3}" with
"A a;" where A is a struct with a destructor, the compiler segfaults).
-
void bug1087a() { // Bugzilla 1087
dummylabel:
scope(exit)
asm { int 3; }
}
void bug1087b() { // Bugzilla 1894
if (true)
scope(exit)
asm { int 3; }
}
void bug1087c() {
if (false){} else
scope(exit)
asm { int 3; }
}
void bug1087d() {
while(true)
scope(exit)
asm { int 3; }
}
void bug1087e() {
do scope(exit)
asm { int 3; }
while(false)
}
void bug1087f() {
foreach(x; 1..2) scope(exit) asm {int 3; }
}
void bug1087g() {
scope(exit) scope(exit) asm {int 3; }
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
