semicolons (;) are optional, the parser really uses whitespace as separator of statements. This is slightly confusing since semicolons are treated as null-statements. This causes some confusion when writing code like: probe begin {if (1 > 0) log("foo"); else log ("bar");}' There will be an error for the else saying: parse error: expected statement saw: keyword at <input>:1:37 source: probe begin {if (1 > 0) log("foo"); else log ("bar");} After encountering this a couple of time it dawns that one either has to put braces around the then part or remove the semicolon. It would (imho) be better if the null-statement following another statement expression was really silent and optional.
Created attachment 4433 [details] Patch to make null-statement really silent This patch makes sure that any null-statement following another statement expression is considered totally optional making the example compile as expected and without any regressions seen.
(In reply to comment #1) > Created an attachment (id=4433) > Patch to make null-statement really silent As far as I can see, this won't change the behavior of any previously valid scripts; it will only make a difference in this if-else case that currently gives an error. So in that sense, your patch seems harmless. However, I find it a little weird to squash the ';' on blocks and other "compound" statements (if, for, foreach, while). For blocks, I think we do want to parse "{...};" as two statements, even though it shouldn't make much difference. For the others, a singleton body should already eat one semicolon, so you're also eating a second. That means you could do this: if (x) if (y) foo();; else bar() and it will attach the 'else' to the outer 'if'. Normally you can't do that without using braces. Perhaps that's an interesting feature, but I think explaining the ';' rules involved would make it too weird to be very useful. So, I think we shouldn't squash semicolons after blocks, if, for, foreach, and while, and then the patch looks ok to me.
Thanks for the review. I made the changes you suggested and added a testcase. commit 40b71c4777ca110d69d5d61563d032a5ba1355df Author: Mark Wielaard <mjw@redhat.com> Date: Mon Dec 21 22:37:20 2009 +0100 PR11038 Trailing semicolon as null-statement confusing. * parse.cxx (parser::parse_statement): Squash semicolon after non-block-like statements. * testsuite/buildok/semicolon.stp: New test.