No error mark on Groovy code that does not compile

[mauromol]

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]

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]

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]

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]

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:

Different package:

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]

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

[eric-milles]

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]

Ready to test

[mauromol]

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:

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

[eric-milles]

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.

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

[mauromol]

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

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