Community
Participate
Working Groups
With 3.7M4 with API tools enabled, I've seen this error logged (no associated backtrace). Not sure what it means or whether the user is supposed to resolve it? Could not locate method MIVariableObject(Lorg/eclipse/cdt/dsf/mi/service/MIVariableManager;Lorg/eclipse/cdt/dsf/mi/service/MIVariableManager$VariableObjectId;Lorg/eclipse/cdt/dsf/mi/service/MIVariableManager$MIVariableObject;Z)V An exception stack trace is not available.
I'm getting similar errors with Linux Tools. Should I try to make a small sample project? Or is this a common error? Could not locate method TmfEventRequest(Ljava/lang/Class<+Lorg/eclipse/linuxtools/tmf/core/event/ITmfEvent;>;Lorg/eclipse/linuxtools/tmf/core/timestamp/TmfTimeRange;JII)V ...
It was some additional logging added to help track down issues finding a referenced member in the workspace. It isn't a very helpful message, but if you are encountering them often it could indicate a problem in API Tools (so a test case would be useful). This was brought up in Bug 229673.
*** Bug 456945 has been marked as a duplicate of this bug. ***
I've been able to reproduce something like Dennis' occurrence from Xtext in bug 456945 by changing the return type of their CompilationTestHelper#compile: public <T> T compile(Iterable<? extends CharSequence> sources, IAcceptor<Result> acceptor) throws IOException { This error arises as org.eclipse.pde.api.tools.internal.util.Signatures.matchesSignatures(java.lang.String, java.lang.String) doesn't properly handle generic types. In this Xtext case, Util.getMethod() is trying to resolve #compile with the following qualified signature: (Ljava.lang.Iterable<+Ljava.lang.CharSequence;>;Lorg.eclipse.xtext.util.IAcceptor<Lorg.eclipse.xtext.xbase.compiler.CompilationTestHelper$Result;>;)TT; But JDT produces the following signature for the above method: (QIterable<+QCharSequence;>;QIAcceptor<QResult;>;)QT; Signatures.matchesSignature isn't doing type erasure. Rather than performing our own method resolution, we should let JDT do the heavy lifting and use IType#findMethods().
New Gerrit change created: https://git.eclipse.org/r/44715
This change is wrong: changing the gentrified type to something incompatible should produce an error and does not. The real problem here is that we Signatures doesn't handle extends-style generics (and possibly super).
I realize I should have summarized my findings here (mostly for my benefit). The logging error occurs because API Tools is trying to resolve a method in a source file given the signature from the corresponding class file. The stack trace can be seen in bug 456945 (thanks Dennis). There are two types of methods causing lookup failures: 1. Methods with generics: This is Marc-Andre case in comment 2 and Dennis' case in bug 456945. The cause is that the Signatures class, which does method signature matching using the JDT Signature class, doesn't properly handle generics. Digging into it, I realized it was also mismatching some generics. This failure to match is in part due to bug 463533, but the Signatures class doesn't handle variable types well either. 2. Constructors on inner classes: This is James' case described in comment 0. These constructors are a special case method as the JVM passes along the outer instance as the first parameter, and and so we could never hope to successfully match methods just by comparing method signatures. My Gerrit patches fix case #1, but I realized that they don't address case #2. but my original approach described in comment 4, leveraging JDT's IType#findMethods(), is better. My confusion in comment 6 was actually due to bug 434408, where API Tools is not reporting method argument type changes.
Created attachment 252277 [details] CDT DSF API baseline target I've updated the Gerrit patch to handle both cases described in comment 7: * I fixed up the Signatures class to handle some corner cases * I fixed up Util#getMethod(), which attempts to resolve a method signature from a binary .class file to an IMethod from a source file, to use JDT's IType#findMethods() to do the heavy lifting in matching methods. The code still uses Signatures if JDT returns multiple matching methods. * I further fixed up Util#getMethod() to do some special lookups when the method signature appears to be a constructor and it's an inner class. With bug 463533 fixed, case #1 is difficult to trigger. Although the Signatures class still had some errors (as evidenced by some of the tests I added to SignatureTests, and now fixed), those errors would have resulted in some method being wrongly matched (false positive) rather than claiming no method was actually found (false negative) as was happening previously. The easiest way to verify case #2 this is to run with my API Baselines from Targets patch for bug 324310. Unfortunately this is quite network intensive! 1. Clone the CDT repository (https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/) 2. Select their cdt-e4.5.target as your target platform 3. Download the attached target file: it references CDT features for the DSF stuff 4. Create an API Baseline around the cdc-api.target 5. Open MIVariableManager.MIVariableObject
Since many platform bundles are moved to Java 7/8 we should consider this as major issue and fix ASAP. There is a patch: PDE team, please consider to review it soon. To validate the fix, checkout org.eclipse.core.databinding.property and revert commit http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a49c16f6fe864442b9ca58cd951515af414ffe17. The project should have now 3 errors as described in bug 477875 comment 0.
(In reply to Andrey Loskutov from comment #9) > Since many platform bundles are moved to Java 7/8 we should consider this as > major issue and fix ASAP. There is a patch: PDE team, please consider to > review it soon. > > To validate the fix, checkout org.eclipse.core.databinding.property and > revert commit > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=a49c16f6fe864442b9ca58cd951515af414ffe17. > > The project should have now 3 errors as described in bug 477875 comment 0. With or without Brians patch I still get these 3 errors.
I'll investigate.
(In reply to Brian de Alwis from comment #11) > I'll investigate. Any update here Brian?
Sorry, this fell off the side of my plate. The problem here is that the SimpleListProperty class has generic parameters and the method signatures are generic too. Here's a cut down example: public abstract class SimpleListProperty<S, E> extends ListProperty<S, E> { protected void doSetList(S source, List<E> list) {} } As a .class file, the doSetList method has signature 'doSetList(Ljava.lang.Object;Ljava.util.List;Lorg.eclipse.core.databinding.observable.list.ListDiff;)V'. But JDT's model method has signature 'doSetList(QS;QList<QE;>;QListDiff<QE;>;)V'. In this case, mapping the S and E to j.l.Object is more complex.
I've updated the patch on Gerrit to add support for stripping and rewriting parameterized types. Basically we first use JDT to try to resolve the requested method. If that doesn't work, we then look through the defined methods and compare method signatures (by erasing generic typing information and expanding parameterized types so as to match the delta keys (method signatures as found in the .class files). This fixes Andrey's case in comment 9, but I'll re-review tomorrow.
I cleaned up the patch a bit. We no longer get the 'Could not locate method …' error, but API Tools now reports that SimpleListProperty has API additions. The class method comparisons aren't quite right. I'll dig into this a bit more tomorrow.
Oops, I never pushed up the revised patch. Now done. The example referenced in comment 13 used the wrong method: > Here's a cut down example: > > public abstract class SimpleListProperty<S, E> extends ListProperty<S, E> > { protected abstract void doSetList(S source, List<E> list, ListDiff<E> diff); I've opened bug 484268 on the resulting 'Missing @since tag' errors.
any update here?
(In reply to Vikas Chandra from comment #17) > any update here? There's a revised patch at https://git.eclipse.org/r/44715/ I haven't been able to get to examining bug 484268.
Even with the patch 44715/11, I get these errors Description Resource Path Location Type The major version should be incremented in version 1.6.0, since API breakage occurred since version 1.5.0 MANIFEST.MF /org.eclipse.core.databinding.property/META-INF line 5 Version Numbering Problem The method org.eclipse.core.databinding.property.list.SimpleListProperty.doSetList(Object, List, ListDiff) that has to be implemented has been added SimpleListProperty.java /org.eclipse.core.databinding.property/src/org/eclipse/core/databinding/property/list line 92 Compatibility Problem The method org.eclipse.core.databinding.property.map.SimpleMapProperty.doSetMap(Object, Map, MapDiff) that has to be implemented has been added SimpleMapProperty.java /org.eclipse.core.databinding.property/src/org/eclipse/core/databinding/property/map line 94 Compatibility Problem The method org.eclipse.core.databinding.property.set.SimpleSetProperty.doSetSet(Object, Set, SetDiff) that has to be implemented has been added SimpleSetProperty.java /org.eclipse.core.databinding.property/src/org/eclipse/core/databinding/property/set line 91 Compatibility Problem
I think it will be good to split into different independent scenarios ( via different bugs) and have fixes for each.
Sorry Vikas — I thought I had replied to comment 19, but it seems to have disappeared into the ether. The patch at https://git.eclipse.org/r/44715/ is valid and closes off this bug. This bug, the "Cannot locate method xxx" is caused by problems resolving a signature to a JDT IMethod. The doSetXXX() issues you found in comment 19 is what I noted in comment 16 and filed as bug 484268. I'd hoped to have fixed this for M6. I'll take a look at bug 484268 either this week or next week. But since bug 484268 causes false positives, there's no sense committing this patch until bug 484268 is fixed.
I've pushed up a revised patch against master, along with a patch for bug 484268.
What is the easiest way to recreate This bug, the "Cannot locate method xxx" is caused by problems resolving a signature to a JDT IMethod. in latest Neon build?
I can't reproduce the CDT MIVariableManager/MIVariableObject, even if I go back to their 8_7 branch. It may be that JDT fixed up Type#getMethod(). I'll try digging some more to see if I can reproduce it. Note to self: the particular CDT commit that would seem to line up with my investigations in comment 8 is 1502c78cd6a999ee54af8d1f486faac87476ff90.
Gerrit change https://git.eclipse.org/r/44715 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=24f00d7ad2beed8ce21d56a9c7e251e2dea399c6
Thanks Brian. Used the test case to understand the changes. They look good !
based on test SignatureTests::testTypeMatches at http://download.eclipse.org/eclipse/downloads/drops4/I20160427-2000/testresults/html/org.eclipse.pde.api.tools.tests_ep46I-unit-lin64_linux.gtk.x86_64_8.0.html
