bug: Unqualified type access becomes fully qualified in some circumstances (noclasspath)

[slarse]

This bug specifically affects the method JDTTreeBuilderHelper#createTypeAccessNoclasspath

spoon/src/main/java/spoon/support/compiler/jdt/JDTTreeBuilderHelper.java

Lines 635 to 649 in 3a8d04d

	<T> CtTypeAccess<T> createTypeAccessNoClasspath(SingleNameReference singleNameReference) {
	final CtTypeReference<T> typeReference = jdtTreeBuilder.getFactory().Core().createTypeReference();
	if (singleNameReference.binding == null) {
	typeReference.setSimpleName(CharOperation.charToString(singleNameReference.token));
	} else {
	typeReference.setSimpleName(CharOperation.charToString(singleNameReference.binding.readableName()));
	}
	CtReference packageOrDeclaringType = jdtTreeBuilder.getReferencesBuilder().getDeclaringReferenceFromImports(singleNameReference.token);
	if (packageOrDeclaringType != null) {
	// must be implicit as a SingleNameReference is not qualified, see #3363
	packageOrDeclaringType.setImplicit(true);
	}
	jdtTreeBuilder.getReferencesBuilder().setPackageOrDeclaringType(typeReference, packageOrDeclaringType);
	return jdtTreeBuilder.getFactory().Code().createTypeAccess(typeReference);
	}

My previous fix (PR #3364 for issue #3363) was only partially successful. Apparently, it can happen that the packageOrDeclaringType variable is null (duh), and then it must be made implicit afterward This occurs when the JDT compiler can't resolve a package or declaring type. This occurs for example in the code below, where Spoon will guess that the type belongs to the CU's package.

package pkg;

public class Cls {
    public static void main(String[] args) {
        SomeClass.someMethod(args);
    }
}

The type access to SomeClass will become explicitly qualified as pkg.SomeClass.

The fix is simple, I'm working on a PR.