Community
Participate
Working Groups
Bug 430818 and bug 338785 tried to add quick fixes for IProblem.ParsingErrorInsertToComplete. But since the fixes only solve a few very specific cases of ParsingErrorInsertToComplete, the net effect is that the quick fix lightbulb shows up in many cases where no actual fix is available (see e.g. bug 434188 comment 7). We currently don't know how to compute the quick fix availability accurately enough. QuickFixProcessor#hasCorrections(ICompilationUnit, int) needs to be very fast, (see Javadoc), and it doesn't get the necessary context to do any further analysis on the actual problem location. A solution could be to at least make the IProblem's arguments available for QuickFixProcessors, so that e.g. the quick fix for bug 338785 can only show up if the proposed insertion is "finally". That would need an API addition. Note that the right solution for bug 430818 / bug 434188 is not this mechanism, but a fix for the bad recovery (bug 430336).
> A solution could be to at least make the IProblem's arguments available for > QuickFixProcessors, so that e.g. the quick fix for bug 338785 can only show > up if the proposed insertion is "finally". That would need an API addition. See https://wiki.eclipse.org/Evolving_Java-based_APIs_3#.222.22_Convention . interface IQuickFixProcessor2 extends IQuickFixProcessor could add a variant: boolean hasCorrections(ICompilationUnit unit, int problemId, String[] problemArguments); Callers should use this variant if available and pass the arguments from CorrectionEngine#getProblemArguments(IMarker) or IJavaAnnotation#getArguments(). Javadoc of IQuickFixProcessor#hasCorrections(..) needs to properly document the special behavior. (In Java 8, we would just add a default method to IQuickFixProcessor, but jdt.ui won't use Java 8 in Mars.)
