Community
Participate
Working Groups
If an annotation processor adds a warning, such as via this code, messager.printWarning(mirror.getPosition(), message + annoValue.getValue()); all quick fix options loaded from clicking in the gutter disappear. They are still available from the problems view. Note that it's not just quick fixes from the particular annotation processor (or annotation processors in general), but all quick fixes for any error/warning (unimported type, missing field declaration, etc).
This actually looks to be a problem in the jdt-ui component. APT adds a categorized problem via the CompilationParticipant in jdt-core, and this seems to break the quick-fixes for all other reported problems. Let me know if you need a detailed repro for the problem.
>Let me know if you need a detailed repro for the problem. A simple test case would be good. Also: which build?
Created attachment 48150 [details] Project that exhibits bug
The attached project can be imported to reproduce the bug. This was tested with 3.2.1 build M20060810-0800-win32.zip. To reproduce, import the project into your workspace. Open Test.java. Right-click on the gutter of the line that contains "InputStream s;", and select Quick-fix. You should only get an option to rename. If you remove the annotation on the file, then try right-clicking for the quick-fix, you will see the other options, including import java.io.InputStream. Let me know if you need any more info.
Problem is in org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation() makeConsistent collects Java problems only if the CU is not consistent any more (ReconcileWorkingCopyOperation.makeConsistent(CompilationUnit, IProblemRequestor) line 128) however, notifyParticipants is called every time and APT creates problems every time So after a reconcile after no changes, a new problem reporting seesion is started but only APT problems are reported. Quick fix doesn't know what to fix and only suggests the 'Rename' quick assist. So maybe - notifyParticipants should only be called when the file is not consistent or - APT has to check cu.isConsistent before collecting problems I think the first option is easier for participants. I realized that quick fixes happens to cause several unnecessary reconciles. I'll fix that.
After discussing with Martin, it appears that the original problem is caused by IProblemRequestor#beginReporting() and endReporting() being called with no acceptProblem() for Java problems even if forceProblemDetection is off. This causes the Java problems to be removed. Jess, would it be acceptable to not notify participants of problems if the working copy is already consistent and forceProblemDetection is off ?
> Jess, would it be acceptable to not notify participants of problems if the > working copy is already consistent and forceProblemDetection is off ? Yes, this seems like correct behavior to me.
+1 for 3.2.1. When participants are contributing problems but forceProblemDetection is off, these problems shouldn't be reported, as they are not accurately representing the set of detected problems. In 3.3, we may want to expose the state of the force flag in the reconcile context, for participants to avoid wasting their time detecting problems unless they will be reported for real.
Created attachment 49051 [details] Proposed fix and regression test
Fix and regression test released for 3.2.1 in R3_2_maintenance branch and released for 3.3 M2 in HEAD.
Verified for 3.2.1 using build M20060908-1655
Verified for 3.3 M2 using build I20060918-0010.
