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

Will McQueen updated GROOVY-7617:
---------------------------------
    Description: 
In Groovy, the scope of a labelled statement seems to be leaking so that break 
statements occurring outside the labelled statement are still valid and in 
scope for that label. This issue is reproducible only when the labelled 
statement is not a block (eg, when it's not something like.... 
*mylabel:\{...\}* ).

For example...

Groovy code is shown below. The issue here is that this code compiles and 
causes infinite output because the 2nd reference of mylabel is in scope when it 
shouldn't be.
{code}
mylabel: for (x in [1,2]) {
  println "first"
  break mylabel
}

for (x in [3,4]) {
  println "second"
  break mylabel  //2nd reference of mylabel
}
{code}
{panel}
Output:
first
second
second
second
second
second
...
{panel}

Java code is shown below. As expected, this won't compile because the 2nd 
reference to 'mylabel' is out of scope:
{code}
mylabel: for (int x : Arrays.asList(1,2)) {
  System.out.println("first");
  break mylabel;
}

for (int x : Arrays.asList(3,4)) {
        System.out.println("second");
        break mylabel;  //won't compile: "Undefined label: 'mylabel'"
}
{code}

  was:
In Groovy, the scope of a labelled statement seems to be leaking to other 
labelled statements that use the same label. This issue is reproducible only 
when the labelled statement is not a block (eg, when it's not something 
like.... *mylabel:\{...\}* ).

Groovy code is shown below. The issue here is that this compiles and causes 
infinite output because the 2nd reference of mylabel seems to be referencing 
the first labelled statement instead of its own (ie, instead of the 2nd 
labelled statement).
{code}
mylabel: for (x in [1,2]) {
  println "first"
  break mylabel
}

for (x in [3,4]) {
  println "second"
  break mylabel  //2nd reference of mylabel
}
{code}
{panel}
Output:
first
second
second
second
second
second
...
{panel}

Java code is shown below. As expected, this won't compile because the 2nd 
reference to 'mylabel' is out of scope:
{code}
mylabel: for (int x : Arrays.asList(1,2)) {
  System.out.println("first");
  break mylabel;
}

for (int x : Arrays.asList(3,4)) {
        System.out.println("second");
        break mylabel;  //won't compile: "Undefined label: 'mylabel'"
}
{code}


> Label is leaking scope when applied to a statement other than a block 
> statement
> -------------------------------------------------------------------------------
>
>                 Key: GROOVY-7617
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7617
>             Project: Groovy
>          Issue Type: Bug
>          Components: Compiler
>    Affects Versions: 2.4.5
>         Environment: Mac OS X 10.10.5
>            Reporter: Will McQueen
>
> In Groovy, the scope of a labelled statement seems to be leaking so that 
> break statements occurring outside the labelled statement are still valid and 
> in scope for that label. This issue is reproducible only when the labelled 
> statement is not a block (eg, when it's not something like.... 
> *mylabel:\{...\}* ).
> For example...
> Groovy code is shown below. The issue here is that this code compiles and 
> causes infinite output because the 2nd reference of mylabel is in scope when 
> it shouldn't be.
> {code}
> mylabel: for (x in [1,2]) {
>   println "first"
>   break mylabel
> }
> for (x in [3,4]) {
>   println "second"
>   break mylabel  //2nd reference of mylabel
> }
> {code}
> {panel}
> Output:
> first
> second
> second
> second
> second
> second
> ...
> {panel}
> Java code is shown below. As expected, this won't compile because the 2nd 
> reference to 'mylabel' is out of scope:
> {code}
> mylabel: for (int x : Arrays.asList(1,2)) {
>   System.out.println("first");
>   break mylabel;
> }
> for (int x : Arrays.asList(3,4)) {
>       System.out.println("second");
>       break mylabel;  //won't compile: "Undefined label: 'mylabel'"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to