digitalmars.D.bugs - [Issue 200] New: Statement *must* follow label
- d-bugmail puremagic.com Jun 16 2006
- Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Jun 16 2006
- pragma <pragma_member pathlink.com> Jun 16 2006
- BCS <BCS pathlink.com> Jun 17 2006
- d-bugmail puremagic.com Jun 19 2006
- d-bugmail puremagic.com Jun 30 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: ; } --
Jun 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
Jun 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
Jun 16 2006
BCS <BCS pathlink.com> 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.
Jun 17 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: {} } --
Jun 19 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) --
Jun 30 2006