Thread overview
[Issue 200] New: Statement *must* follow label
Jun 16, 2006
d-bugmail
Jun 16, 2006
Frits van Bommel
Jun 16, 2006
pragma
Jun 17, 2006
BCS
Jun 19, 2006
d-bugmail
Jul 01, 2006
d-bugmail
June 16, 2006
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: ;
}


-- 

June 16, 2006
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
June 16, 2006
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 capture and rewinding the parse position - that's how I found #199 as well.

- EricAnderton at yahoo
June 17, 2006
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
> capture and rewinding the parse position - that's how I found #199 as well.
> 
> - 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.
June 19, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=200


smjg@iname.com changed:

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




------- Comment #1 from smjg@iname.com  2006-06-19 09:42 -------
The spec gives:

    LabelledStatement:
        Identifier ':' Statement

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

(In reply to comment #0)
> 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: {}
    }


-- 

July 01, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=200


bugzilla@digitalmars.com changed:

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




------- Comment #2 from bugzilla@digitalmars.com  2006-06-30 20:30 -------
Fixed DMD 0.162
(changed spec to allow ';' as empty statement after label)


--