Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 225181 - Not possible to have two API problems with the same ids on the same resource
Summary: Not possible to have two API problems with the same ids on the same resource
Status: VERIFIED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: API Tools (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.4 M7   Edit
Assignee: Michael Rennie CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 225826 229783 230010 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-01 15:09 EDT by Olivier Thomann CLA
Modified: 2008-05-07 11:17 EDT (History)
3 users (show)

See Also:


Attachments
Proposed fix (1.51 KB, patch)
2008-04-01 15:16 EDT, Olivier Thomann CLA
no flags Details | Diff
Proposed fix (2.79 KB, patch)
2008-04-01 15:23 EDT, Olivier Thomann CLA
no flags Details | Diff
Proposed fix (2.49 KB, patch)
2008-04-01 18:23 EDT, Olivier Thomann CLA
no flags Details | Diff
Proposed fix (4.60 KB, patch)
2008-05-01 12:22 EDT, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2008-04-01 15:09:49 EDT
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.
Comment 1 Olivier Thomann CLA 2008-04-01 15:16:42 EDT
Created attachment 94415 [details]
Proposed fix

Michael, please review.
Comment 2 Darin Wright CLA 2008-04-01 15:18:08 EDT
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.
Comment 3 Olivier Thomann CLA 2008-04-01 15:22:22 EDT
charStart/charEnd => field name.
I'll make changes to my previous patch as it was using too many problem elements.
Comment 4 Olivier Thomann CLA 2008-04-01 15:23:37 EDT
Created attachment 94417 [details]
Proposed fix

More simple fix.
Comment 5 Olivier Thomann CLA 2008-04-01 15:27:55 EDT
Michael, the last fix passes all our tests.
I checked the test case mentioned in comment 0 and it now works as expected.
Comment 6 Olivier Thomann CLA 2008-04-01 18:21:08 EDT
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).
Comment 7 Olivier Thomann CLA 2008-04-01 18:23:56 EDT
Created attachment 94453 [details]
Proposed fix
Comment 8 Olivier Thomann CLA 2008-04-01 18:24:19 EDT
Released for 3.4M7.
Darin, please verify.
Comment 9 Olivier Thomann CLA 2008-04-04 21:25:12 EDT
*** Bug 225826 has been marked as a duplicate of this bug. ***
Comment 10 Olivier Thomann CLA 2008-04-09 20:05:53 EDT
Reopen to assign to Darin.
Comment 11 Olivier Thomann CLA 2008-04-09 20:06:19 EDT
Fixed.
Darin, please verify.
Comment 12 Darin Wright CLA 2008-05-01 10:11:16 EDT
Re-opening.
Comment 13 Darin Wright CLA 2008-05-01 10:12:07 EDT
*** Bug 229783 has been marked as a duplicate of this bug. ***
Comment 14 Olivier Thomann CLA 2008-05-01 10:31:06 EDT
This is a consequence of not having the charStart/charEnd in the problem hashCode and equals.
Comment 15 Darin Wright CLA 2008-05-01 10:34:16 EDT
Problem is that char ranges go stale in problems/filters, as code is modified. We should be considering problem arguments (which include member names).
Comment 16 Michael Rennie CLA 2008-05-01 10:42:15 EDT
the current code in HEAD uses the problem id, the resource path and the problem arguments.
Comment 17 Olivier Thomann CLA 2008-05-01 10:48:03 EDT
I don't think the @since tag problem contains the member name. Maybe it should and this would work.
Comment 18 Darin Wright CLA 2008-05-01 10:58:48 EDT
The message could be "Missing @since tag on {0}". Then we add type name, field name, or method name/siganture.
Comment 19 Olivier Thomann CLA 2008-05-01 11:04:53 EDT
Yes, this would be one way to fix it.
Comment 20 Olivier Thomann CLA 2008-05-01 11:32:29 EDT
I'll fix it.
Comment 21 Olivier Thomann CLA 2008-05-01 12:22:37 EDT
Created attachment 98327 [details]
Proposed fix

I would contribute this for 3.4M7
Comment 22 Olivier Thomann CLA 2008-05-01 12:27:53 EDT
Released for 3.4M7.
Comment 23 Olivier Thomann CLA 2008-05-01 12:28:34 EDT
Fixed. Michael, please verify.
Comment 24 Michael Rennie CLA 2008-05-01 12:49:57 EDT
verified
Comment 25 Olivier Thomann CLA 2008-05-07 11:17:36 EDT
*** Bug 230010 has been marked as a duplicate of this bug. ***