[ 
https://issues.apache.org/jira/browse/GROOVY-12478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King updated GROOVY-12478:
-------------------------------
    Fix Version/s: 7.0.0-alpha-1

> yield before the last statement of an arrow-switch arm is ignored when the 
> switch is compiled as a statement
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-12478
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12478
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 6.0.0
>            Reporter: Paul King
>            Assignee: Paul King
>            Priority: Major
>             Fix For: 7.0.0-alpha-1, 6.0.1
>
>
> A {{yield}} that is not the last statement of an arrow-switch block arm is 
> silently ignored when the switch ends up classified as a statement: execution 
> falls through to the rest of the arm instead of completing the switch.
> {code:groovy}
> def pick(boolean flag) {
>     switch (1) {
>         case 1 -> {
>             if (flag) yield 'first'
>             yield 'second'
>         }
>     }
> }
> assert pick(true) == 'first'   // fails on 6.0.0: 'second'
> {code}
> The same thing happens when the switch's value is discarded (the code after 
> the conditional {{yield}} still runs), and a {{yield}} inside a loop within 
> the arm no longer compiles:
> {code:groovy}
> def pick(List xs) {
>     switch (1) {
>         case 1 -> {
>             for (x in xs) { if (x > 2) yield "big $x" }
>             yield 'none'
>         }
>     }
> }
> // 6.0.0: "the yield statement is only allowed inside a switch expression"
> {code}
> ||Case||5.1.2||6.0.0-RC-1||6.0.0-RC-3 / 6.0.0||
> |Trailing switch, {{pick(true)}}|'first'|'first'|*'second'*|
> |Value discarded, conditional {{yield}}|arm exits|arm exits|*falls through*|
> |{{yield}} inside a loop in the arm|works|works|*compile error*|
> |{{return switch (...)}}|'first'|'first'|'first'|
> Behaviour is the same in dynamic Groovy and under {{@CompileStatic}}.
> *Cause:* since GROOVY-12408 a trailing switch is a statement, and the parser 
> rewrites statement-position arrow switches via 
> {{AstBuilder.armCodeAsStatement}}, which replaces each {{yield x}} with a 
> plain expression statement {{x}}. Only the last value of the arm reaches 
> {{ReturnAdder}}, so a final {{yield}} still appears to work, but any earlier 
> {{yield}} loses its jump. The rewrite does not descend into loops, so a 
> nested {{yield}} survives as a {{YieldStatement}} and is then rejected.
> The related rejection of {{return}}, {{break}} and {{continue}} in every 
> arrow arm ("switch expression does not support `return`") dates from when 
> arrow switches were implemented as closures, where a {{return}} would only 
> have left the closure; 6.0 compiles switches inline and makes 
> statement-position ones real switch statements, so that restriction should 
> now depend on position as well.
> *Expected:* {{yield}} keeps its early-exit meaning wherever the switch's 
> position puts it. GROOVY-12408 was meant to change only how a trailing switch 
> is encoded, and 4.x/5.x code had to use {{yield}} in block arms of exactly 
> these switches. In return position, a {{yield}} should behave like 
> {{return}}. Elsewhere it should evaluate its expression and exit the switch.
> *Suggested fix:* keep the {{YieldStatement}} s instead of flattening them. 
> Let {{ReturnAdder}} turn the yields belonging to a return-position switch 
> into returns, searching the whole arm including loops but stopping at nested 
> switch expressions and closures. Compile any remaining {{yield}} in a switch 
> statement as "evaluate, discard, jump to the switch's end label", which also 
> makes the loop case work.
> *Workaround:* write return switch (...) { ... } so the switch stays an 
> expression, or restructure the arm so its only {{yield}} is the last 
> statement (e.g. if/else with a {{yield}} in each branch).



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to