1. A simplified version of the SwitchStatement has syntax that can be described by
SwitchStatement = "switch" "(" Expression ")" "{"
{ OneSwitch }
"}" .
OneSwitch = CaseLabel ":" { CaseLabel ":" } Statement { Statement } .
CaseLabel = "case" Constant | "default" .
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, that the types of all the constants and the type of the selector Expression must be compatible, and that there may be only one default label. Although not illegal, a SwitchStatement without any instances of OneSwitch 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 CaseLabel 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.
Develop the productions given above in such a way that this C# constraint is enforced.