[jira] [Commented] (GROOVY-8169) StaticCompilationVisitor.visitForLoop sets Parameter origin type, which prevents access to original source type and location

["Shil Sinha (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999249#comment-15999249 ] 

Shil Sinha commented on GROOVY-8169:
------------------------------------

That line was added as part of the fix for GROOVY-5641, but all tests currently pass without it everywhere from 2_4_X to master. That way, it certainly does look unnecessary. Do you happen to have an example of something that fails due to the loss of uninferred type information?

> StaticCompilationVisitor.visitForLoop sets Parameter origin type, which prevents access to original source type and location
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-8169
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8169
>             Project: Groovy
>          Issue Type: Bug
>          Components: Static compilation
>            Reporter: Eric Milles
>
> {{StaticCompilationVisitor.visitForLoop}} has call to {{forLoop.getVariable().setOriginType(componentType)}}.  I think this call is unnecessary as the inferred type is set on the previous line.  By replacing the origin type, it is no longer possible to determine the uninferred type of the parameter or the source location of the ClassNode.  Additionally, I think the semantics of origin type is not being preserved by overwriting the value.
> Example:
> {code}
> @CompileStatic
> def m() {
>   List<String> strings = ...
>   for (String s in strings) {
>   }
> }
> {code}
> In this example, the second occurrence of String is replaced in the AST by the first and so the source position of the ClassNode after "for" and before "s" is lost.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)