Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Statically imported fields causing compile error in annotation arrays values #245

Closed
AntonPanikov opened this issue Dec 14, 2016 · 3 comments

Comments

@AntonPanikov
Copy link

If you try to use statically imported fields in annotation array value, it will looks like 'cannot be resolved to a variable' compile error. Actually code compiles and runs fine. It was working about month ago (can not tell exactly version, about mid of November), but right now it is broken.

I am using Groovy-Eclispe: 2.9.2.xx-201612141446-e46

There is simple example:
TestStrings.groovy

package test

interface TestStrings {
    public static final String ONE = 'one'
    public static final String TWO = 'two'
    public static final String THREE = 'three'
}

TestAnnotation.groovy

package test

@interface TestAnnotation {
    String[] value()
}

Test.groovy

package test

import static test.TestStrings.*

class Test {

    @TestAnnotation(value = [ONE, TWO])
    static main(args) {
        println 'hello groovy'
    }

}

Test.groovy will have two compile errors: 'ONE cannot be resolved to a variable' and the same for TWO. If you replace 'String[] value' to just 'String value', then using '@TestAnnotation(value = ONE)' will not cause this error. If you replace ONE/TWO by TestString.ONE/TWO, this will go away also.

@eric-milles
Copy link
Member

I'll have a look. As you say, this should work. I have tried to add test cases for as many of these types of scenarios that I can think of. I'm not sure if the star import is the difference here.

@eric-milles
Copy link
Member

This should be fixed now. Also, you could use import aliases on any of those constants and that would work now -- was also broken. Thanks for raising this issue.

@AntonPanikov
Copy link
Author

It is fixed now. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants