Community
Participate
Working Groups
build I20040118 - Runtime, SWT, UI and Text loaded from head - other external plug-ins included on PDE class path of some other projects - did a search for refs to the constructor Action(String, String) - it found some "potential match"es in JavaOutlineInformationControl that were unexpected: org.eclipse.jdt.internal.ui.text.JavaOutlineInformationControl.LexicalSortingAction.LexicalSortingAction(JavaOutlineInformationControl, TreeViewer) (potential match) org.eclipse.jdt.internal.ui.text.JavaOutlineInformationControl.OutlineLabelProvider.OutlineLabelProvider(JavaOutlineInformationControl) (potential match) org.eclipse.jdt.internal.ui.text.JavaOutlineInformationControl.OutlineSorter (potential match) org.eclipse.jdt.internal.ui.text.JavaOutlineInformationControl.ShowOnlyMainTypeAction.ShowOnlyMainTypeAction(JavaOutlineInformationControl, TreeViewer) (potential match) The first and last are good guesses, but the middle two are not. The corresponding line in OutlineLabelProvider is: super(AppearanceAwareLabelProvider.DEFAULT_TEXTFLAGS | JavaElementLabels.F_APP_TYPE_SIGNATURE, AppearanceAwareLabelProvider.DEFAULT_IMAGEFLAGS); - For this one I can see how it would get confused. It doesn't know the superclass, and can't infer that both arguments are ints, not strings. The OutlineSorter line is: private class OutlineSorter extends ViewerSorter { - This is clearly not a constructor call, and OutlineSorter has no constructor.
Here are some other strange ones: org.eclipse.pde.internal.ui.view.DependenciesView.DummyPart (potential match) line: static class DummyPart implements IWorkbenchPart { org.eclipse.team.internal.ccvs.ui.CVSCompareRevisionsInput.VersionCompareContentProvider (potential match) line: class VersionCompareContentProvider implements IStructuredContentProvider { org.eclipse.team.internal.ccvs.ui.CVSCompareRevisionsInput.VersionCompareDiffNode.VersionCompareDiffNode(CVSCompareRevisionsInput, ITypedElement, ITypedElement) (potential match) line: super(left, right); org.eclipse.team.internal.ui.synchronize.FlatModelProvider.FlatModelProviderDescriptor (potential match) line: public static class FlatModelProviderDescriptor implements ISynchronizeModelProviderDescriptor { It seems to be flagging class declarations for nested classes in the same CU that has other potential matches.
Moving to core for comments.
If time permit
Nick, are you still able to reproduce this one? As there's some code change in this area since this bug has been opened, I get some difficulty to reproduce it. If you can, please precise exactly what are projects in your workspace (saying if they are CVS/imported source/binary. Thanks
Yes it still occurs in 3.1 M7. I have the following loaded from CVS: org.eclipse.platform.doc.user org.eclipse.platform-feature org.eclipse.releng org.eclipse.sdk-feature org.eclipse.swt.win32.win32.x86 org.eclipse.test.performance.win32 org.eclipse.core.commands org.eclipse.core.filebuffers org.eclipse.core.resources org.eclipse.core.runtime org.eclipse.core.system org.eclipse.core.tests.harness org.eclipse.jface org.eclipse.jface.text org.eclipse.osgi org.eclipse.platform org.eclipse.platform.doc.isv org.eclipse.swt org.eclipse.swt.examples org.eclipse.test org.eclipse.test.performance org.eclipse.text org.eclipse.ui org.eclipse.ui.browser org.eclipse.ui.editors org.eclipse.ui.examples.components org.eclipse.ui.examples.javaeditor org.eclipse.ui.examples.multipageeditor org.eclipse.ui.examples.propertysheet org.eclipse.ui.examples.rcp.browser org.eclipse.ui.examples.readmetool org.eclipse.ui.ide org.eclipse.ui.presentations.r21 org.eclipse.ui.tests org.eclipse.ui.tests.rcp org.eclipse.ui.views org.eclipse.ui.win32 org.eclipse.ui.workbench org.eclipse.ui.workbench.compatibility org.eclipse.ui.workbench.texteditor And the following added to my search path (via the Plug-ins view): org.eclipse.jdt.ui org.eclipse.help.ui org.eclipse.team.ui org.eclipse.team.cvs.ui org.eclipse.pde.ui (and some others) It probably would suffice to load the platform-ui module from CVS, then add the plug-ins above to the search path. To show the problem in M7, you need to add the following to Action: protected Action(String text, String foo) { this(text); } And then search for refs to this constructor.
Actually, you don't need to change Action. Searching for refs to the existing (String, ImageDescriptor) constructor shows the problem too.
I would say that it's an invalid bug as it works as designed... Found references are in a .class file with attached source. As they are in a .class file, these references are supposed to be correct (otherwise .class would not have been generated) and are not bound (I think it's for performance issue - but should ask specialists to know more about this point). So, there's no binding on these references and then search engine is not able to verify more than syntax matches the given pattern. That's why it flags all these matches as "potential" ones. In constructor calls and message sends, search engine cannot know arguments type without binding and then syntax match is only done on selector and arguments count. This is what happened for all cases you highlighted as strange and unfortunately there's nothing we can do in these cases. If these matches really disturb you in search view, you still have the possibility to ignore potential matches using General>Search preferences page...
Ooops, sorry, I was wrong... The matches you highlighted should not be reported.
However, I'm afraid search engine cannot do anything here even for these cases. Problem here is in fact for super references. While verifying syntax for this kind of match, there's no type name for constructor call. So, the only verification which is done is on arguments count. Search engine usually expected that there will have a resolution and invalid matches as those reported will be filtered using constructor binding... AS I said in previous comment, we do not have any here and that's why searche engine let these matches reported. So, finally my conclusion will be the same than previous comment => there's unfortunately nothing search engine can do here expect no reporting these matches at all. As user still have the possibility to hide them using preferences, I think it would be better to let current behavior as this. If you agree please close this bug, thx
I understand that the best it can do is to match arbitrary two-argument constructors in types that also have a reference to the class containing the constructor (Action). Does it actually restrict it based on refs to the containing class, or does it just search for refs to any two-argument constructor? For the case: org.eclipse.jdt.internal.ui.text.JavaOutlineInformationControl.OutlineSorter it has neither, and the match is being reported against the type, not a constructor call. For the case: org.eclipse.jdt.internal.ui.text.JavaOutlineInformationControl.OutlineLabelProvider.OutlineLabelProvider(JavaOutlineInformationControl) it calls a two-argument super constructor, but has no reference to Action.
It actually just searches for refs to any two-argument constructor and need to resolve to filter inaccurated matches. That's why the second case cannot be filtered. As there's no binding, all unbound contructors with two arguments will be reported as potential one... However, the first case can be fixed. Arguments count was not verified for implicit contructors calls.
Fixed and relased in HEAD. OutlineSorter case is no longer reported as this was a match on a synthetic constructor with a different number of arguments. Other cases, are still reported as potential ones to avoid missing some interesting... [jdt-core internal] Changes done in ContructorLocator.resolve(ContructorDeclaration,boolean). Test case added in JavaSearchBugsTests. Note that this test does verify that bug is really fixed, but only that it has no impact on existing behavior. It was not really possible to put a test in this suite to verify that bug is effectively fixed as it appears only to potential match found in plugin dependencies... To test the fix manually, execute following scenario: 1) check-out org.eclipse.jface project in a workspace and open Java perspective 2) open plugin perspective 3) in Plug-ins view, select org.eclipse.jdt.ui and add it to Java Search 4) in Java perspective, open Action class 5) search to constructor (Sting,int) in workspace 6) You should find 20 references and JavaOutlineInformationControl.OutlineSorter should not be in these matches...
Verified in I20050526-2000 according to comment 12.
