Community
Participate
Working Groups
With the way the equals() method is defined in org.eclipse.pde.api.tools.internal.problems.ApiProblem, it is not possible to have more than one problem of the same kind in the same resource. If you set up API tools for the ui.workbench project, inside the class org.eclipse.ui.presentations.AbstractPresentationFactory, there are four new fields that are not tagged with @since tags, but we report the error only on one of them. This is a serious limitation. I think the fix is to use the charStart, charEnd, extra arguments into account in the equals method. This might required to also adjust the hashCode implementation.
Created attachment 94415 [details] Proposed fix Michael, please review.
In this case, wouldn't field name be more important thatn char start/end? We might want to consider problem arguments/parameters (not sure which is the member name), to be more flexible.
charStart/charEnd => field name. I'll make changes to my previous patch as it was using too many problem elements.
Created attachment 94417 [details] Proposed fix More simple fix.
Michael, the last fix passes all our tests. I checked the test case mentioned in comment 0 and it now works as expected.
In fact we don't need the kind, element type and flags as this is part of the id. So I only kept the charStart and charEnd values. (In reply to comment #2) > In this case, wouldn't field name be more important thatn char start/end? We > might want to consider problem arguments/parameters (not sure which is the > member name), to be more flexible. I don't think we need to consider arguments or parameters as this is related to the id. We should not report more than once the same problem (same id) on the same member (determined uniquely by charStart/charEnd).
Created attachment 94453 [details] Proposed fix
Released for 3.4M7. Darin, please verify.
*** Bug 225826 has been marked as a duplicate of this bug. ***
Reopen to assign to Darin.
Fixed. Darin, please verify.
Re-opening.
*** Bug 229783 has been marked as a duplicate of this bug. ***
This is a consequence of not having the charStart/charEnd in the problem hashCode and equals.
Problem is that char ranges go stale in problems/filters, as code is modified. We should be considering problem arguments (which include member names).
the current code in HEAD uses the problem id, the resource path and the problem arguments.
I don't think the @since tag problem contains the member name. Maybe it should and this would work.
The message could be "Missing @since tag on {0}". Then we add type name, field name, or method name/siganture.
Yes, this would be one way to fix it.
I'll fix it.
Created attachment 98327 [details] Proposed fix I would contribute this for 3.4M7
Released for 3.4M7.
Fixed. Michael, please verify.
verified
*** Bug 230010 has been marked as a duplicate of this bug. ***