RFR: 8264258: Unknown lookups in the java package give misleading compilation errors

Srikanth Adayapalam sadayapalam at openjdk.java.net
Tue Apr 20 06:51:10 UTC 2021


On Sun, 11 Apr 2021 12:49:35 GMT, Jesper Steen Møller <jespersm at openjdk.org> wrote:

> Unknown lookups in the java package give misleading compilation errors

Changes requested by sadayapalam (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4064:

> 4062:             if (!location.name.isEmpty()) {
> 4063:                 if (location.kind == PCK && !site.tsym.exists() && location.name != names.java) {
> 4064:                     return diags.create(dkind, log.currentSource(), pos,

This works, but I am not sure it is the fix we want. I would be curious to find out why site.tsym.exists() returns false for the java PackageSymbol. What I find with some preliminary debugging is that we end up creating a PackageSymbol for `java' that is distinct from the PackageSymbol java that is the owner of the PackageSymbol java.lang.

In this block of code

// Import-on-demand java.lang.
                PackageSymbol javaLang = syms.enterPackage(syms.java_base, names.java_lang);
                if (javaLang.members().isEmpty() && !javaLang.exists())
                    throw new FatalError(diags.fragment(Fragments.FatalErrNoJavaLang));
                importAll(make.at(tree.pos()).Import(make.QualIdent(javaLang), false), javaLang, env);

com.sun.tools.javac.comp.TypeEnter.ImportsPhase#resolveImports

at the importAll call if you have a breakpoint and query the javaLang.exists() and javaLang.owner.exists() they both answer true.

So it looks fishy to me that we somehow end up with a distinct PackageSymbol for java that answers false for exists() even as there exist other symbols that answer true.

If you debug through javac as it attributes:

Object o1 = java.lang.String.class;

while attributing the FieldSelect node you can see that the PackageSymbol for java.lang has a owner that is distinct from the PackageSymbol for siteSym - so we do right thing by coalescing the symbols somehow - how is what needs further analysis.

test/langtools/tools/javac/8264258/MisleadingTypeNotFound.java line 5:

> 3:  * @bug 8264258
> 4:  * @summary unknown.Class.default gives misleading compilation error
> 5:  * @compile/fail/ref=MisleadingTypeNotFound.out -Xlint:all -Werror -XDrawDiagnostics -XDdev MisleadingTypeNotFound.java

Summary looks incorrect, copying over Valhallaisms ??

test/langtools/tools/javac/8264258/MisleadingTypeNotFound.java line 10:

> 8: 
> 9: public class MisleadingTypeNotFound {
> 10: 

It is a bit confusing. The misleading message is not about Type not found, but existing package being reported as non-existent. So we should change these names of classes/files/jbs descriptions etc suitably. 

MisleadingNonExistentPathError ??

test/langtools/tools/javac/8264258/MisleadingTypeNotFound.java line 21:

> 19:         Class<?> c3 = unknownpkg.NotFound.class;
> 20: 
> 21:         // Not found, but in the 'java' package which is in scope as per JLS 6.3 and observable as per JLS 7.4.3

Could you just for completeness, add the new java.lang() case also ? Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3428


More information about the compiler-dev mailing list