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

Import all does not work for long packages #724

Closed
AntonPanikov opened this issue Sep 19, 2018 · 4 comments
Closed

Import all does not work for long packages #724

AntonPanikov opened this issue Sep 19, 2018 · 4 comments
Assignees
Labels
Milestone

Comments

@AntonPanikov
Copy link

I have an issue with the code that is compiled properly, but as soon as I open a particular file it is complains that it can not resolve a type and mark is as compile error:

Groovy:unable to resolve class

But it is only marked inside editor, not in problems or in tree and only when file is opened.

It is easy to reproduce:

package main

import test.*
import test.sub.*

class Test {
    static main(args) {
        Imported1 t1 = null
        Imported2 t2 = null
        Imported3 t3 = null
        Imported4 t4 = null
    }
}

and just create 4 empty classes:

package test

class Imported1 {
}
package test

class Imported2 {
}
package test.sub

class Imported3 {
}
package test.sub

class Imported4 {
}

When you open the Test class you will noticed that the first two classes references is fine, while the second two is complaining about:

Groovy:unable to resolve class Imported3
Groovy:unable to resolve class Imported4

I am on 3.1.0.xx-201809172153-e47

@eric-milles
Copy link
Member

LookupEnvironment.createPackage is checking for a type to be sure there is no collision with the requested package. Because of Groovy's extra resolution pathway, the package "test" already has a MissingTypeBinding entry for "sub". This fails the test and so null is returned (last line of snippet below).

public PackageBinding createPackage(char[][] compoundName) {
	PackageBinding packageBinding = getPackage0(compoundName[0]);
	if (packageBinding == null || packageBinding == TheNotFoundPackage) {
		packageBinding = new PackageBinding(compoundName[0], this, this.module);
		this.knownPackages.put(compoundName[0], packageBinding);
		if (this.module != null) {
			packageBinding = this.module.addPackage(packageBinding, true);
			this.knownPackages.put(compoundName[0], packageBinding); // update in case of split package
		}
	}

	for (int i = 1, length = compoundName.length; i < length; i++) {
		// check to see if it collides with a known type...
		// this case can only happen if the package does not exist as a directory in the file system
		// otherwise when the source type was defined, the correct error would have been reported
		// unless its an unresolved type which is referenced from an inconsistent class file
		// NOTE: empty packages are not packages according to changes in JLS v2, 7.4.3
		// so not all types cause collision errors when they're created even though the package did exist
		ReferenceBinding type = packageBinding.getType0(compoundName[i]);
		if (type != null && type != TheNotFoundType && !(type instanceof UnresolvedReferenceBinding))
			return null;

@eric-milles
Copy link
Member

This all changed for Groovy-Eclipse when this was added to ResolveVisitor to try and identify star imports that referred to types (see #640):

            for (ImportNode importNode : module.getStarImports()) {
                if (importNode.getEnd() > 0) {
                    String importName = importNode.getPackageName();
                    importName = importName.substring(0, importName.length()-1);
                    ClassNode type = ClassHelper.makeWithoutCaching(importName);
                    if (resolve(type, false, false, true)) {
                        importNode.setType(type);
                        type.setStart(importNode.getStart() + 7);
                        type.setEnd(type.getStart() + importName.length());
                    }
                }
            }

@eric-milles eric-milles self-assigned this Sep 19, 2018
@eric-milles eric-milles added this to the v3.1.0 milestone Sep 19, 2018
eric-milles added a commit that referenced this issue Sep 20, 2018
This prevents LookupEnvironment.createPackage from returning null
because a package was tried as a type and a missing binding was stored
@eric-milles
Copy link
Member

Ready to test

@AntonPanikov
Copy link
Author

Tested on 3.1.0.xx-201809201450-e47
It is working now.

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