Community
Participate
Working Groups
I20070321-0010 - new workspace - import org.eclipse.debug.core and org.eclipse.jdt.junit as binary plug-ins - search for references to org.eclipse.debug.internal.core.LaunchConfiguration.launch(String,IProgressMonitor) Was: 1 match in org.eclipse.jdt.debug.ui_*.jar Expected: 2 more matches in org.eclipse.jdt.junit_*.jar as when searching for org.eclipse.debug.core.ILaunchConfiguration.launch(String,IProgressMonitor). The additional matches should have MethodReferenceMatch#isSuperInvocation() == true.
*** Bug 208756 has been marked as a duplicate of this bug. ***
Looks like a side effect of fix for bug 73401 and must be definitely fixed for 3.4...
In fact, this regression has been introduced while fixing bug 156491 and bug 157814... Bug 156491 comment 6 warned about potential missing matches when the hierarchy includes an interface, but I removed them after remark done in bug 157814 comment 8. I'll try to figure out how can I solve this bug without introducing regressions on those bugs...
> Looks like a side effect of fix for bug 73401 > and must be definitely fixed for 3.4... IMHO this is severe and should be fixed with the next 3.3.x release as well! We rely heavily on the call hierachy and getting incomplete results is the worst thing that could happen. I do not know the internals, but won't refactoring be affected by this?
(In reply to comment #4) > IMHO this is severe and should be fixed with the next 3.3.x release as well! We > rely heavily on the call hierachy and getting incomplete results is the worst > thing that could happen. > I agree it seems a good candidate for 3.3.2. However, I didn't want to promise thing I cannot afford and first wanted to have an idea of what could be the fix for this to know whether it really could go into the maintenance stream or not... Saying that, I'm currently testing a fix which does not seem to be too aggressive and maybe put in 3.3.2 if all tests pass... > I do not know the internals, but won't refactoring be affected by this? > No. Refactoring uses specials flags in the search pattern to ignore declaring and return types during the search and so, is not affected by this issue. That's why it's not so critical as you may think initially and explain why I didn't work on this earlier...
Created attachment 82186 [details] Proposed patch All tests pass with this patch which simply extends the verification for super invocation to all super interfaces of the method actual receiver type.
Jerome, Philippe, OK to backport this safe change to 3.3.2?
Released for 3.4M4 in HEAD stream.
Created attachment 82753 [details] Proposed patch for 3.3.2
+1 for backporting to 3.3.2
Released for 3.3.2 in R3_3_maintenance stream.
Without this fix, valid matches are missed. As a consequence the user will not find where his/her code is used. Refactoring will be affected as well and risks to produce code that doesn't compile. This fix needs to be included in 3.3.2. Philippe please approve.
+1 for 3.3.2
Verified for 3.4 M4 using build I20071211-0010
