RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure.

[Liam Miller-Cushon]

I did some more testing and am seeing regressions with a few existing
annotation processors. In some cases the processors relied on a completion
failure being thrown, and adding explicit checks for error types fixes them.

There was another example I'm less sure about, where a compilation that
previously failed with a 'class file not found' error now succeeds but the
processor sees incorrect information. In the example below the class file
for the interface B is missing, and its element kind is reported as CLASS.

=== L.java
class A {}
interface B {}
class L extends A implements B {}
=== T.java
class T {}
=== P.java
import java.util.Set;
import javax.annotation.processing.*;
import javax.lang.model.*;
import javax.lang.model.element.*;
import javax.lang.model.type.*;

@SupportedAnnotationTypes("*")
public class P extends AbstractProcessor {

  @Override
  public SourceVersion getSupportedSourceVersion() {
    return SourceVersion.latest();
  }

  @Override
  public boolean process(Set<? extends TypeElement> annotations,
RoundEnvironment roundEnv) {
    for (TypeMirror st :
        processingEnv
            .getTypeUtils()
            .directSupertypes(processingEnv.getElementUtils(
).getTypeElement("L").asType())) {
      System.err.println(st.getKind() + ": " + st);
      Element te = ((DeclaredType) st).asElement();
      System.err.println(" " + te.getKind() + ": " + te);
    }
    return false;
  }
}
===

$ javac *.java && rm B.class
# with JDK 10+43
$ javac -fullversion -implicit:none -sourcepath : -processor P T.java
javac full version "10+43"
DECLARED: A
 CLASS: A
DECLARED: B
error: cannot access B
  class file for B not found
  Consult the following stack trace for details.
  com.sun.tools.javac.code.Symbol$CompletionFailure: class file for B not
found
...
$ echo $?
1

# with http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01/
$ javac  -implicit:none -sourcepath : -processor P T.java
DECLARED: A
 CLASS: A
DECLARED: B
 CLASS: B
...
$ echo $?
0

On Tue, Feb 13, 2018 at 4:26 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:

> On 12.2.2018 19:50, Liam Miller-Cushon wrote:
>
>> Hi Jan,
>>
>> I've run into the same problem a few times, and made some half-baked
>> experiments around not caching completion failures [1]. The approach you
>> describe sounds good to me. Also,
>>
>
> Thanks.
>
> * this will fix JDK-8177436 [2] too
>>
>
> I double-checked, and it indeed fixes that.
>
> * there's a minor typo in the javadoc
>> for DeferredCompletionFailureHandler - "throw the the client code"
>>
>
> Fixed in the updated webrev.
>
> Thanks for the feedback,
>     Jan
>
>
>> [1]
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-Mar
>> ch/010883.html
>> <http://mail.openjdk.java.net/pipermail/compiler-dev/2017-Ma
>> rch/010883.html>
>> [2] https://bugs.openjdk.java.net/browse/JDK-8177436
>> <https://bugs.openjdk.java.net/browse/JDK-8177436>
>>
>> On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda <jan.lahoda at oracle.com
>> <mailto:jan.lahoda at oracle.com>> wrote:
>>
>>     Hi,
>>
>>     Currently, when a calling some API methods, the client (e.g.
>>     TaskListener, an annotation Processor or a JavacTask client) may get
>>     a CompletionFailure, if the given Symbol was not completed yet. This
>>     is not only problematic for the clients, but if the client catches
>>     and ignores the exception, the javac may be unable to report an
>>     appropriate error.
>>
>>     The proposed patch here:
>>     -separates "user " and "javac" modes, in which CompletionFailure
>>     handling differs a bit
>>     -in javac mode, CompletionFailures should be handled as they are
>>     currently
>>     -in user (code) mode, when a CompletionFailure is thrown (and would
>>     go outside of an API method), the API method will suppress the
>>     exception, and the Symbol's state (completer, kind, type) will be
>>     restored to original when the mode is switched back to javac mode.
>>     If the Symbol is then completed again inside javac, the
>>     CompletionFailure is thrown again and the appropriate errors are
>>     reported.
>>
>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8187950
>>     <https://bugs.openjdk.java.net/browse/JDK-8187950>
>>     Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/
>>     <http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/>
>>
>>     How does this look?
>>
>>     Thanks,
>>          Jan
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180213/a21d7808/attachment.html>