Failed to load package-info defaults when parsing

[zcai1]

At commit b8b16a3, we noticed the following test case:

import java.util.Set;

public class EisopIssue270 {
    void foo(Set<Object> so, Set<? extends Object> seo) {
        so.retainAll(seo);
    }
}

reports an unexpected output (using nullness checker):

EisopIssue270.java:5: error: [argument.type.incompatible] incompatible argument for parameter arg0 of retainAll.
        so.retainAll(seo);
                     ^
  found   : @UnknownKeyFor Set<capture#528[ extends @UnknownKeyFor Object super @KeyForBottom Void]>
  required: @UnknownKeyFor Collection<?[ extends @UnknownKeyFor Object super @UnknownKeyFor Void]>
1 error

The required type should have a wildcard with @KeyForBottom Void lower bound, but we get @UnknownKeyFor Void instead. The issue is first introduced by #251, after reverting the PR, the issue is gone. However, we don't think reverting the PR is the correct solution because the following test case will not produce the unexpected output:

import java.util.*;

public class EisopIssue270 {
    boolean foo1(List<Object> l1, List<? extends Object> l2) {
        return l1.size() == l2.size();
    }

    void foo2(Set<Object> so, Set<? extends Object> seo) {
        so.retainAll(seo);
    }
}

After some investigation, we believe the added code in #251 may try to get the declaration annotations of an annotated jdk element while the AnnotatedTypeFactory is currently parsing a file. When it's parsing, the AnnotatedTypeFactory.getDeclAnnotations(Element) will either return the cached result or only the annotations in the element to prevent parsing a different file.

For collections under java.util, package-info.java in the annotated jdk defines the default for lower bound should be KeyForBottom. The first test case will fail because when it calls getDeclAnnotations on java.util, the AnnotatedTypeFactory is parsing and java.util is not cached. The second test case doesn't fail because foo1 will load java.util into the cache. Therefore, this issue may or may not appear for the same set of source files depending on the file processing order of javac.

[wmdietl]

Thanks for the detailed write-up!