www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 200] New: Statement *must* follow label

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=200

           Summary: Statement *must* follow label
           Product: D
           Version: 0.160
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: ericanderton yahoo.com


This one is pretty simple.  The parser seems to think that the only valid way
to use a label is if a statement directly follows it.  But shouldn't a label be
valid all by itself, if its the last line of a scope?

void main(){
        x:
}

test.d(3): found '}' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement
test.d(3): found 'EOF' instead of statement

The workaround for this one is dead simple: just use a ';' right after the
label.  IMO, that doesn't look like valid code.

void main(){
        x: ;
}


--
Jun 16 2006
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
d-bugmail puremagic.com wrote:

 This one is pretty simple.  The parser seems to think that the only valid way
 to use a label is if a statement directly follows it.  But shouldn't a label be
 valid all by itself, if its the last line of a scope?
 
 void main(){
         x:
 }


[snip]


 The workaround for this one is dead simple: just use a ';' right after the
 label.  IMO, that doesn't look like valid code.


Or, you know, you could just use "return" instead of "goto x" :P
Jun 16 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <e6v4p9$c5f$1 digitaldaemon.com>, Frits van Bommel says...

d-bugmail puremagic.com wrote:

 This one is pretty simple.  The parser seems to think that the only valid way
 to use a label is if a statement directly follows it.  But shouldn't a label be
 valid all by itself, if its the last line of a scope?
 
 void main(){
         x:
 }


[snip]


 The workaround for this one is dead simple: just use a ';' right after the
 label.  IMO, that doesn't look like valid code.


Or, you know, you could just use "return" instead of "goto x" :P


Not always. :)

The example in the bug report is merely the most simple case for Walter's sake
Here's a real-world example:

http://www.dsource.org/projects/ddl/browser/trunk/enki/EnkiParser.d#L91

The above shows a different variation of a workaround: using "{}".  But the
problem still stands.  The code generator needs a way to provide a way to jump
to a known pass/fail point where it is known that there are no other
instructions that could generate side-effects.  Each "{}" closure also maps to a
particular production in the input grammar, and has its own variables for input


- EricAnderton at yahoo
Jun 16 2006
parent BCS <BCS pathlink.com> writes:
pragma wrote:

 In article <e6v4p9$c5f$1 digitaldaemon.com>, Frits van Bommel says...

Or, you know, you could just use "return" instead of "goto x" :P


 
 
 Not always. :)
 
 The example in the bug report is merely the most simple case for Walter's sake
 Here's a real-world example:
 
 http://www.dsource.org/projects/ddl/browser/trunk/enki/EnkiParser.d#L91
 
 The above shows a different variation of a workaround: using "{}".  But the
 problem still stands.  The code generator needs a way to provide a way to jump
 to a known pass/fail point where it is known that there are no other
 instructions that could generate side-effects.  Each "{}" closure also maps to
a
 particular production in the input grammar, and has its own variables for input

 
 - EricAnderton at yahoo


any reason to not allow this?

foo: 	{
	// bail out of this scope
		if(i==0) break foo;

		writef("i!=0\n");

		(i<0)?1++:i--;

	// same effect as continue so no need for that
		goto foo;
	}

Yes its a bit contrived, but the idea could make some more complicated 
code (auto or hand generated) a bit cleaner. I have a few times put 
something in a function just so that a return could be used to leave the 
scope.
Jun 17 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=200


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com





The spec gives:

    LabelledStatement:
        Identifier ':' Statement

i.e. a label prefixes a statement - it doesn't act as a statement by itself.



 The workaround for this one is dead simple: just use a ';' right after the
 label.  IMO, that doesn't look like valid code.


Indeed, it isn't according to the spec, and for good reasons.  Use an empty
BlockStatement instead.

    void main() {
        x: {}
    }


--
Jun 19 2006
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=200


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED





Fixed DMD 0.162
(changed spec to allow ';' as empty statement after label)


--
Jun 30 2006