Community
Participate
Working Groups
Created attachment 82960 [details] Source code which generates the bug Build ID: M20071023-1652 Steps To Reproduce: I am not able to reproduce it in a new test case. I have cleaned my source code to make it as short as possible and attached it to this bug. I have put only the source code, because with external libs it is quite huge. You will have many errors due to missing external librairies but the bug "Missing code implementation..." will still be in the error list. So the steps are : 1- Create a new projet 2- Extract the attached source zipped code in the project folder 3- Compile with eclipse 4- Look for the 'Missing code implementation in the compiler' error More information: It seems to be caused by inner class extensions using generalized classes... Don't hesitate to contact me to know more.
Suspecting some interference of ParameterizedTypeBinding with generic type layer (SourceTypeBinding/MemberTypeBinding) and a missing #erasure() call somewhere. Olivier - if you could reproduce, this would be great (then reassign back to me)
The problem occurs because there is a wrong reference in javadoc. The guilty javadoc is inside the member type ParentModelListener located in the top level type com.nextep.datadesigner.gui.model.TableDisplayConnector. The method is #dispatchEvent(ChangeEvent event, IObservable source, Object data). Are you using the batch compiler or you are compiling from within the IDE ? Are you compiling in 1.5 or 1.6 mode ? If you comment out this comment, your code should compile. I will isolate a small test case. Thanks for the test case.
You are right!! When i comment the javadoc comments on dispatchEvent the compiler bug disapear. BUT, this seems to me weird that the javadoc comment on the setModel method doesn't throw the same compiler error since there is the exact same mistake in the javadoc reference on this method. I am compiling directly from the eclipse IDE, nothing specific. I am compiling with jdk 1.6.0_02-b06 with the compliance set to "6.0". Thank you for your help and reactivity. (In reply to comment #2) > The problem occurs because there is a wrong reference in javadoc. > The guilty javadoc is inside the member type ParentModelListener located in the > top level type com.nextep.datadesigner.gui.model.TableDisplayConnector. > The method is #dispatchEvent(ChangeEvent event, IObservable source, Object > data). > Are you using the batch compiler or you are compiling from within the IDE ? > Are you compiling in 1.5 or 1.6 mode ? > If you comment out this comment, your code should compile. > I will isolate a small test case. > Thanks for the test case.
Added regression test org.eclipse.jdt.core.tests.compiler.regression.JavadocTest_1_5#_testBug209936() Eric, once fixed please reenable the test. The problem is reproducable either in 1.6 mode (where -enableJavadoc is enabled by default) or in 1.5 mode with -enableJavadoc. We might want to backport to 3.3.2.
The test doesn't contain the right error. This will need to be fixed once we don't throw the missing implementation error anymore.
Released some changes to at least locate the error on the offending AST node.
Created attachment 84203 [details] [proposed patch + test case] on top v826 - all jdt.core tests OK Now handle the ProblemReasons.ReceiverTypeNotVisible pb id warning/error message is now displayed correctly: sample: Javadoc: The method foo(Object, Object) from the type Z<T>.Member is not visible
Patch released for 3.4M4 in HEAD.
New proposed behavior will consist in converting all generic types to raw types, when referenced from within a Javadoc. As a consequence, and contrary to comment#7, correct behavior should not raise a warning against the method not being visible, but rather against the type not being visible. Member#foo(Object, Object) ^^^^^^ Javadoc: Invalid member type qualification
see also bug 80257, bug 87868, bug 83127 for related issues
Created attachment 84710 [details] [proposed patch + test cases] on top v827 - all jdt.core tests OK Frederic - may you please review proposed patch - thanks
(In reply to comment #11) > Created an attachment (id=84710) [details] > [proposed patch + test cases] on top v827 - all jdt.core tests OK > > Frederic - may you please review proposed patch - thanks > It seems that something is wrong as while testing your patch I saw that the tests you added to JavadocTest_1_5 didn't go into the loop when enclosing level is greater than 1. Investigating further, it looks like that the solution should be more simple than the proposed patch.
Created attachment 85267 [details] [proposed patch + test case] on top v829 - all jdt.core tests OK improved fix: new method added to LookupEnvironment - Philippe may you please review - thanks
I am not a big fan of adding #deepConvertToRawType(...). Feels like we should try to retrofit it in existing conversion method. Wondering why conversion doesn't occur already when resolving a type name, could be that the javadoc node is not doing the right thing.
Created attachment 85366 [details] [proposed patch + test case] on top v829 - all jdt.core tests OK (In reply to comment #14) Improved patch. Confirmed with Philippe that Javadoc had the specific need to (deep) raw convert references. #deepConvertToRawType(...) moved from LookupEnvironment to Util for possible reuse.
I could imagine having a force flag on #convertToRawType(...) to force conversion of enclosing type. #convertToRawType(boolean forceRawEnclosingType) All existing senders (26) would call it with 'false', only javadoc would call it with 'true'.
Created attachment 86312 [details] [proposed patch + test case] on top v830 - all jdt.core tests OK better patch
Patch released for 3.4M5 in HEAD.
fixed
Created attachment 88878 [details] [ready to import project to test the bug] It might be not obvious in the bug history, but a partial fix for this bug went into M4, so that, at this level, the "missing compiler implementation" message is not displayed anymore. To test this bug, use a 3.4 M3, import the above project and observe the error message: "Missing code implementation in the compiler" After M4, this message won't show up anymore: - in M4: a single line was added to the ProblemReporter to prevent the above message - in M5, the bug was "really" fixed, and partial fix that went into M4 was removed. Sorry for the confusion.
(In reply to comment #20) - to sum-up (with the above attached project) - before M4: missing compiler message - at M4 level: warning Javadoc: The method foo(Object, Object) from the type Z<T>.Member is not visible - at M5 level: no warning Explanation: with the latest "real" fix (that went into M5), all type generic type references in Javadoc comments are converted to raw type, the reason why the warning message displayed at M4 level is not displayed anymore.
Thanks for the explanation. Verified for 3.4M5 using I20080205-0010
