You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But our bindings are generating it with a key like this:
Lg1/t/s/def/Generic$Member<>;
With the incorrect key, our dom-search can't look for the proper signature.
This also causes normal search to fail if we run eclipse with the dom-based-operations but the normal search. So this is a bug in dom-based operations that needs to be fixed regardless.
Many test cases appear to be failing over this or a similar issue.
The text was updated successfully, but these errors were encountered:
This issue also brings up the possible difference between key and signature. The API doesn't really distinguish but I know that different calls often need slightly different syntax, which is annoying. I believe I made a small PR to address this in a different part of the code earlier.
JavaSearchGenericTypeTests.testParameterizedTypeSingleArgument02 is a test that demonstrates the bug.
The resolved source type should have a unique key like this:
Lg1/t/s/def/Generic<Ljava/lang/Exception;>.Member;
But our bindings are generating it with a key like this:
Lg1/t/s/def/Generic$Member<>;
With the incorrect key, our dom-search can't look for the proper signature.
This also causes normal search to fail if we run eclipse with the dom-based-operations but the normal search. So this is a bug in dom-based operations that needs to be fixed regardless.
Many test cases appear to be failing over this or a similar issue.
The text was updated successfully, but these errors were encountered: