Community
Participate
Working Groups
Created attachment 109634 [details] Plug-in project to reproduce bug Build ID: I20080617-2000 Steps To Reproduce: 1. Have a compilation unit with 'illogical' JavaDoc (explained in more information). 2. Create an array of compilation units for parsing including the one created in step 1. 3. Create a Parser object with resolveBindings set to false. 4. Call Parser.createASTs(...). 5. An IllegalArgumentException is thrown, while it shouldn't. The easiest way to reproduce the bug is using our attached sample code: i) run plug-in project ("CreateASTs") in Eclipse; ii) in the launched environment open "someproject" ; iii) then press the "reproduce bug" button. More information: We encountered this strange bug while testing our codechecker tool on large projects. It occurs when there is a JavaDoc comment inside a method body _and_ the next element is 'final'. Such a JavaDoc is meaning-less according to conventions but should be harmless according to Java specifications as it is a comment. The stack trace shows the IllegalArgumentException on the compilation unit immediately after the 'offending' compilation unit. More specific research showed us, JavaDoc reference didn't get reset and this causes the problem on the package statement of next compilation unit in Parser.consumePackageDeclarationName().
Thanks for the good test case. The field javadoc should indeed be reset for a local variable. It is done properly for a field declaration, but never for a local. This would be a good candidate for 3.4.1. Jérôme, +1 for 3.4.1 ?
Created attachment 109677 [details] Proposed fix
Released for 3.5M2. Added regression tests in org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0693 org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0694
(In reply to comment #1) > Thanks for the good test case. > > The field javadoc should indeed be reset for a local variable. > It is done properly for a field declaration, but never for a local. > > This would be a good candidate for 3.4.1. > Jérôme, +1 for 3.4.1 ? > It looks like I didn't see this backport request. Is this a regression comparing to 3.3.x?
Verified for 3.5M2 using I20080914-2000
