1. One version of the SwitchStatement has syntax that can be described by
SwitchStatement = "switch" "(" Expression ")" "{"
{ CaseLabelList Statement { Statement } }
[ "default" ":" { Statement } ]
"}" .
CaseLabelList = CaseLabel { CaseLabel } .
CaseLabel = "case" [ "+" | "-" ] Constant ":" .
Constant = IntConst | CharConst | "true" | "false" | "null" .
but, as usual, this has to be supplemented by semantic constraints. Among these are, fairly obviously, that no Constant may appear more than once as a CaseLabel within a single SwitchStatement and that the types of all the constants and the type of the selector Expression must be compatible. Although not illegal, a SwitchStatement without any internal clauses is of little use, and might elicit a warning to the user if it is detected.
How would the productions be attributed to allow such constraint checking to proceed?
2. In C, C++ and Java the statements that follow each CaseLabelList are not restricted in any way, although it is common to find that the last of them is a BreakStatement or ReturnStatement; if absent the semantics prescribe that control then falls through to the next option. This is expressly forbidden in C#, which requires that if the Statement sequence is not empty it must terminate with an unguarded explicit BreakStatement or ReturnStatement.
Can you develop the productions given above in such a way that this C# constraint is enforced syntactically, or find some other constraint analysis technique that will do so?