Bug 355402

Description Tomasz Wesolowski 2011-08-22 11:07:48 EDT

Some CDT quick fix architecture (just like in JDT) depends on ICAnnotation.getId().

However, in CDT it's implemented differently from JDT, namely like this:

> // org.eclipse.cdt.internal.ui.editor.CMarkerAnnotation.getId()
>	public int getId() {
>		if (fIsProblemMarker)
>			return getMarker().getAttribute(ICModelMarker.C_MODEL_PROBLEM_MARKER, -1);
>		return 0;
>	}

compared to JDT:

>	public int getId() {
>		IMarker marker= getMarker();
>		if (marker == null  || !marker.exists())
>			return -1;
>		if (isProblem())
>			return marker.getAttribute(IJavaModelMarker.ID, -1);
>		// (...) [snip commented out block of code]
>		return -1;
>	}

The string constant C_MODEL_PROBLEM_MARKER is defined as:

>	/**
>	 * C model problem marker type (value <code>"org.eclipse.cdt.core.problem"</code>).
>	 * This can be used to recognize those markers in the workspace that flag problems 
>	 * detected by the C compilers.
>	 */
>	public static final String C_MODEL_PROBLEM_MARKER = CCorePlugin.PLUGIN_ID + ".problem"; //$NON-NLS-1$

This means that the CMarkerAnnotations which don't have such attribute defined also don't have an ID (and some quick fix architecture relies on the annotation having an ID). Annotations from Codan-generated markers don't hence respond to getId() properly.

Additionally, the description of this string constant suggests that it's a marker type, not marker attribute key (and indeed it's ONLY used as a marker type in the codebase, usually as an argument to project.findMarkers). Hence it seems that it's used incorrectly in this context.

Looks like a design flaw in CMarkerAnnotation to me, which prevents quick fix processors to operate on some annotations. How to fix it?