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

No error mark on Groovy code that does not compile #708

Closed
mauromol opened this issue Sep 7, 2018 · 10 comments
Closed

No error mark on Groovy code that does not compile #708

mauromol opened this issue Sep 7, 2018 · 10 comments
Assignees
Labels
Milestone

Comments

@mauromol
Copy link

mauromol commented Sep 7, 2018

Consider these Java classes:

package test35;
public class Base {
	public static class Nested {}
}
package test35;
public class Extension extends Base {
}

and this Groovy class:

package test35

import test35.Extension.Nested;

import groovy.transform.CompileStatic

@CompileStatic
class Test35 {
	Nested n
}

Although the equivalent Java code would be valid, the Groovy compiler rejects this code with unable to resolve class test35.Extension.Nested (since Nested is declared in Base, not Extension). However Greclipse does not complain at all, while I would expect an error mark on the import statement, to be consistent with the Groovy compiler.

@eric-milles
Copy link
Member

Imports are checked in ResolveVisitor.visitClass: https://github.com/groovy/groovy-eclipse/blob/master/base/org.codehaus.groovy24/src/org/codehaus/groovy/control/ResolveVisitor.java#L1413

If the class is resolving due to the subclass superclass relationship, no error will be indicated. There is a chance that this is a core Groovy issue.

@mauromol
Copy link
Author

mauromol commented Sep 7, 2018

Could be a Groovy issue even if the compiler fails? Maybe a problem with the static type checker?
On the other hand, I was wondering whether it might be a Groovy compiler fault (since the equivalent Java code compiles).

@eric-milles
Copy link
Member

I'm missing the compiler error when these classes reside in the same package. However, when Base and Extension are in a different package from Test35, the error shows in both the editor and during compilation. Note that Groovy does some extra checking against the types visible within the same package.

@mauromol
Copy link
Author

Hmmm... I'm not sure I'm following. With Greclipse 3.1.0.xx-201809160114-e48, Groovy 2.4 Compiler plugin 3.1.0.xx-201809160114-e48 and Groovy 2.4.15 on the Eclipse project classpath, I don't get any error in the editor for Test35, being it in the same package of Base/Extension classes or not.

Same package:
immagine

Different package:
immagine

Instead, if I build the project with Gradle, I get:

D:\ws\48\path\TestGroovyGradle\src\main\groovy\test35\Test35.groovy: 3: unable to resolve class test35.Extension.Nested
 @ line 3, column 1.
   import test35.Extension.Nested;
   ^

D:\ws\48\path\TestGroovyGradle\src\main\groovy\test35\Test35.groovy: 9: unable to resolve class test35.Extension.Nested
 @ line 9, column 2.
        Nested n
    ^

D:\ws\48\path\TestGroovyGradle\src\main\groovy\test35b\Test35.groovy: 3: unable to resolve class test35.Extension.Nested
 @ line 3, column 1.
   import test35.Extension.Nested;
   ^

D:\ws\48\path\TestGroovyGradle\src\main\groovy\test35b\Test35.groovy: 9: unable to resolve class test35.Extension.Nested
 @ line 9, column 2.
        Nested n
    ^

4 errors

As you can see, the compilation errors involve both Test35 classes (same or different packages).

@eric-milles
Copy link
Member

That's the piece I'm missing. When you compile with Gradle (aka not eclipse) you get an error.

@eric-milles
Copy link
Member

ResolveVisitor.visitClass makes its way into JDTClassNode.resolveFromCompileUnit. It tries the active JDT CompilationUnitScope to look up the type name. It is this lookup that is returning "test35.Base$Nested" for "test35.Extension.Nested" using the Java rules of resolution.

    protected boolean resolveFromCompileUnit(ClassNode type) {
        boolean foundit = super.resolveFromCompileUnit(type);
        recordDependency(type.getName());
        if (DEBUG) {
            log("resolveFromCompileUnit", type, foundit);
        }
        if (foundit) {
            return true;
        }
        if (activeScope != null) {
            // Ask JDT for a source file, visible from this scope
            ClassNode node = activeScope.lookupClassNodeForSource(type.getName(), this);

@eric-milles
Copy link
Member

Ready to test

@mauromol
Copy link
Author

Hi Eric, the error is given in 3.1.0.xx-201809190054-e48, thank you! But the strange thing (I have already observed in other circumstances) is that:

  • the red mark is in the editor, at the import line, in the vertical ruler and in the overview ruler
  • the read mark floats on the package, source folder and project in the Project Explorer
  • however the red mark is not placed on the Groovy class in the Project Explorer

This is annoying, because it's hard to see when there's an error in which class it's located (you have to open the Markers view to find it out).

See this screenshot:
immagine

Here, I would expect to see the red error mark on both test35.Test35 and test35b.Test35.

@eric-milles
Copy link
Member

eric-milles commented Sep 19, 2018

The compilation unit must be built for the error to show. I am seeing the label decoration, so I'm not sure what the difference is.

error

Note: I use the Package Explorer view; the Project Explorer view works quite a bit different.

@mauromol
Copy link
Author

Note: I use the Package Explorer view; the Project Explorer view works quite a bit different.

Indeed, this must be the difference. See #726.

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

No branches or pull requests

2 participants