Bug 437927

Summary:	[quick fix][api] Offer quick fixes for specific cases of IProblem.ParsingErrorInsertToComplete
Product:	[Eclipse Project] JDT	Reporter:	Markus Keller <markus.kell.r>
Component:	UI	Assignee:	JDT-UI-Inbox <jdt-ui-inbox>
Status:	ASSIGNED ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	gautier.desaintmartinlacaze, manju656, noopur_gupta, sandra.lions-piron, stephan.herrmann
Version:	4.4
Target Milestone:	---
Hardware:	All
OS:	All
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=477990
Whiteboard:
Bug Depends on:
Bug Blocks:	338785, 430818, 434188

Description Markus Keller

2014-06-23 08:34:25 EDT

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).

Comment 1 Markus Keller

2014-07-15 08:38:46 EDT

> 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.)