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
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
            asm { int 3; }

void bug1087b() { // Bugzilla 1894
    if (true)
            asm { int 3; }

void bug1087c() {
    if (false){} else
            asm { int 3; }

void bug1087d() {
            asm { int 3; }            

void bug1087e() {
    do scope(exit) 
            asm { int 3; }

void bug1087f() {
   foreach(x; 1..2) scope(exit) asm {int 3; }

void bug1087g() {
   scope(exit) scope(exit) asm {int 3; }

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to