Community
Participate
Working Groups
Build 3.1rc3 The following code causes compiler to reject it due to missing some support for it: package foo; public class ListenerSupport<T, F> { /** * @param <T> * @param <F> */ class Entry<L, R> { // empty } }
Also see bug 29144#c6 for original reported issue.
Offending code path is: org.eclipse.jdt.internal.compiler.problem.ProblemReporter.needImplementation(ProblemReporter.java:3988) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.javadocInvalidType(ProblemReporter.java:3650) at org.eclipse.jdt.internal.compiler.ast.JavadocSingleTypeReference.reportInvalidType(JavadocSingleTypeReference.java:30) at org.eclipse.jdt.internal.compiler.ast.JavadocSingleTypeReference.internalResolveType(JavadocSingleTypeReference.java:66) at org.eclipse.jdt.internal.compiler.ast.Javadoc.resolveTypeParameterTags(Javadoc.java:400) at org.eclipse.jdt.internal.compiler.ast.Javadoc.resolve(Javadoc.java:86) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1069) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1105) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:996) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1112) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:305) at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:560) at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:599) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:165) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:214) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:79) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:718) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:777) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1081) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:98) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044) at org.eclipse.core.runtime.Platform.run(Platform.java:783) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:82) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:147) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:94) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:75) at org.eclipse.jdt.internal.ui.text.JavaReconciler.process(JavaReconciler.java:339) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:204)
Not I needed to use full test case to reproduce (see bug 29144).
Problem occurs on Javadoc ref to 'T' at position 445.
The offending problem reference binding ID is NonStaticReferenceInStaticContext.
Reduced testcase is actually: public class X<T, F> { /** * @param <T> * @param <F> */ static class Entry<L, R> { // empty } }
Problem comes from the fact the reference to type variables occurs from within static context. Does javadoc allow it ?
It feels like when doc single type ref fails locally, it should recurse in enclosing type, as it does for doc message sends; to step away from static context.
comment 7: no javadoc does not allow this kind of reference. On comment 6 sample, javadoc raises 2 warnings: warning - @param argument "<T>" is not a type parameter name. warning - @param argument "<F>" is not a type parameter name.
Good candidate for 3.1.1
Created attachment 23791 [details] Patch to fix this issue Add a specific javadoc message to handle this specific error: "Javadoc: Cannot make a static reference to the non-static type variable {0}"
*** Bug 102735 has been marked as a duplicate of this bug. ***
Created attachment 24384 [details] Complete patch to fix this issue It was not enough just to add specific message for 2 reasons: 1) for @param tag with incorrect tag, we do prefer warn about wrong param name rather than non-static reference in static context 2) javadoc.exe consider reference to enclosing type type variables as invalid, so we have to behave the same way.
Created attachment 24385 [details] Added tests in JavadocTest_1_? classes
I reported https://bugs.eclipse.org/bugs/show_bug.cgi?id=102735 , later marked as a duplicate of this bug. I'm not yet completely sure these are the same bugs, so I wanted to make sure: * Does the new patch fix the bug in which auto-completion of JavaDoc variables will incorrectly use the generic variable of the enclosing type rather than of the enclosed type? * Does the new patch fix the bug that, when the JavaDoc reference correctly refers to the generic variable of the enclosed type, the JavaDoc reference is shown with a yellow underline warning? Cheers, Garret
Patch released in R3_1_maintenance stream. [jdt-core internal] All JDT/Core and JDT/UI tests pass.
According to bug 102735 summary this was a real duplicate... However, it seems real issue was more about code completion in javadoc so I will change this summary and reassign it to correct component...
Verified in 3.2M1 (I20050808-2000)
*** Bug 109108 has been marked as a duplicate of this bug. ***
Verified for 3.1.1 using build M20050923-1430.
