Может ли AbstractProcessor определить, есть ли в аннотированном методе ошибки компиляции?

Question

Моя реализация AbstractProcessor вызывается, даже если аннотированный метод содержит код, который приводит к ошибкам компилятора. (Т.е. процессор запускается при наличии аннотации, цель которой ElementType.METHOD).

Немного поэкспериментировав, у меня сложилось впечатление, что синтаксические ошибки в теле метода приводят к тому, что AbstractProcessor не запускается, тогда как "ссылочные ошибки", fx пытается вызвать закрытый метод, который не может быть достигнут, действительно приводит к вызову AbstractProcessor.

Я рад, что вызывается AbstractProcessor, но мне нужно знать, аннотированный метод содержит какие-либо ошибки.

У меня два вопроса:

1. Как мой код AbstractProcessor может узнать, содержит ли ExecutableElement мой метод ошибки? Мне известно о SuperficialValidation Google Auto, но я не могу заставить его обнаруживать эти ошибки - возможно, он работает только с TypeElements?
2. Могу ли я быть уверен, что все версии компилятора имеют одинаковое поведение в отношении типов ошибок, препятствующих вызову AbstractProcessor, и какие из них позволят ему выполнить свой лог c?

Answer 1

JavaCompiler имеет несколько выполняемых фаз. Вы можете увидеть, завершена ли обработка, из RoundEnvironment.processingOver() и пройти по дереву, используя TreePathScanner. Однако многие фактические ошибки обнаруживаются после завершения обработки аннотации, и их можно найти в диагностике. Возможно, вам удастся найти некоторую информацию, указав DiagnosticListener.

. Есть несколько способов определить, что произошла ошибка при проверке Symbol/Type символа. Используя TreePathScanner внутри visitMethodInvocatio, вы ожидаете, что символ будет методом, но если этот метод не существует, он может быть нулевым или ClassSymbol.