Community
Participate
Working Groups
In the following sample, the @link and @see annotations will link to the wrong method when following the links from the Javadoc view or from the hover popup. Generated javadoc for this sample will link to the correct method. public class SeeTest { /** * Link to string array method: {@link #myMethod(String[], String...)}. * * @see #myMethod(String[], String...) */ public SeeTest() { } /** * My method with single String * * @param param * a string * @param args * variable length args */ public void myMethod(String param, String... args) { } /** * My method with String array. * * @param params * string array * @param args * variable length args */ public void myMethod(String[] params, String... args) { } }
The issue occurs in org.eclipse.jdt.internal.ui.text.javadoc.JavadocContentAccess2.createAST(IJavaElement element, String cuSource) when ASTParser.createAST(IProgressMonitor monitor) is invoked. The source set in ASTParser.setSource(char[] source) contains "String..." in the Javadoc but the result from BodyDeclaration.getJavadoc() after calling ASTParser#createAST changes it to "String". As a result, the correct method is not found and the first method matching the number of parameters is returned in jdt.ui, which is the reported bug. Moving to JDT Core to fix the issue from ASTParser#createAST.
(In reply to Noopur from comment #1) > > The source set in ASTParser.setSource(char[] source) contains "String..." in > the Javadoc but the result from BodyDeclaration.getJavadoc() after calling > ASTParser#createAST changes it to "String". > @Noopur: I see this for BodyDeclaration.getJavadoc() /** * Link to string array method: {@link #myMethod(String[],String)}. * @see #myMethod(String[],String) */ at: Daemon Thread [Text Viewer Hover Presenter] (Suspended) TypeDeclaration(BodyDeclaration).getJavadoc() line: 171 JavadocContentAccess2.getJavadocNode(IJavaElement, String) line: 730 JavadocContentAccess2.javadoc2HTML(IMember, IJavaElement, String) line: 759 JavadocContentAccess2.getHTMLContentFromSource(IJavaElement) line: 671 JavadocContentAccess2.getHTMLContent(IJavaElement, boolean) line: 534 JavadocHover.getHoverInfo(IJavaElement[], ITypeRoot, IRegion, JavadocBrowserInformationControlInput) line: 719 JavadocHover.internalGetHoverInfo(ITextViewer, IRegion) line: 637 JavadocHover.getHoverInfo2(ITextViewer, IRegion) line: 629 BestMatchHover.getHoverInfo2(ITextViewer, IRegion, boolean) line: 164 BestMatchHover.getHoverInfo2(ITextViewer, IRegion) line: 130 JavaEditorTextHoverProxy.getHoverInfo2(ITextViewer, IRegion) line: 86 TextViewerHoverManager$4.run() line: 166 Can you please paste the stack trace where you find String instead of String[]?
(In reply to Manoj Palat from comment #2) > (In reply to Noopur from comment #1) > > > > The source set in ASTParser.setSource(char[] source) contains "String..." in > > the Javadoc but the result from BodyDeclaration.getJavadoc() after calling > > ASTParser#createAST changes it to "String". > > > > @Noopur: I see this for BodyDeclaration.getJavadoc() > /** > * Link to string array method: {@link #myMethod(String[],String)}. ^^^^^^ > * @see #myMethod(String[],String) ^^^^^^ > */ Please check the highlighted type above which is "String" now but was passed as "String...".
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
(In reply to Eclipse Genie from comment #4) > This bug hasn't had any activity in quite some time. Maybe the problem got > resolved, was a duplicate of something else, or became less pressing for > some reason - or maybe it's still relevant but just hasn't been looked at > yet. > > If you have further information on the current state of the bug, please add > it. The information can be, for example, that the problem still occurs, that > you still want the feature, that more information is needed, or that the bug > is (for whatever reason) no longer relevant. > > -- > The automated Eclipse Genie. This issue still occurs in 2019-03.
Something I don't understand about the following code in JavaElementLinks#parseURI(URI): //Shortcut: only check name and parameter count: methods= type.getMethods(); for (int i= 0; i < methods.length; i++) { method= methods[i]; if (method.getElementName().equals(refMemberName) && method.getNumberOfParameters() == paramSignatures.length) return method; } Even though the paramSignatures constructed from the hyperlink is [[QString;, QString;], which appears alright to me, we return with the following: myMethod(String, String ...) Noopur, can you confirm if this is not playing a role here?
