Community
Participate
Working Groups
the following text: ----------------------------------------- // // Created : 25-Nov-2003, 10:00:37 // Description : // Author : Nikolay // Copyright : (c) Teamphone.com Ltd. 2003 - All Rights Reserved // /** * @author Nikolay */ public class A { public A() { } } interface B { public method(final int parameter); } ---------------------------------------------------------- causes a whole series of (if autobuild is on): ----------------------------------------------------------- java.lang.IllegalArgumentException at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:1486) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:701) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations (ASTConverter.java:244) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:183) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:81) at org.eclipse.jdt.core.dom.AST.parseCompilationUnit(AST.java:354) at org.eclipse.jdt.core.dom.AST.parseCompilationUnit(AST.java:247) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartList enerGroup.computeAST(SelectionListenerWithASTManager.java:106) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartList enerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:116) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$1.run (SelectionListenerWithASTManager.java:92) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:62) ------------------------------------------------------------------------
M5
I will investigate.
Reproduced.
The problem comes from the fact that the interface's method has no return type.
Fixed and released in HEAD. Regression test added. In case of an invalid constructor, the body end and the declaration source end were not set when the invalid constructor had no body. The fixed needs to be done in the parser.
*** Bug 47326 has been marked as a duplicate of this bug. ***
*** Bug 48195 has been marked as a duplicate of this bug. ***
I can not reproduce the IllegalArgumentException in build 20031216 Verified for 3.0M6
Using integration build 200401271238 on win2k sp4 jdk 1.4.2_01 If I start typing private Key key; between the java doc for a method and the method body I get a popup saying Error: Java Ast Creation etc. when I reach the "v". Typing the same information before the java doc does not give the error. here is a typical log entry java.lang.IllegalArgumentException at org.eclipse.jdt.core.dom.ASTNode.checkNewChild(ASTNode.java:1101) at org.eclipse.jdt.core.dom.ASTNode.replaceChild(ASTNode.java:1055) at org.eclipse.jdt.core.dom.BodyDeclaration.setJavadoc(BodyDeclaration.java:87) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:339) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:268) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:156) at org.eclipse.jdt.core.dom.AST.parseCompilationUnit(AST.java:932) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.computeAST(SelectionListenerWithASTManager.java:125) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:144) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$1.run(SelectionListenerWithASTManager.java:99) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:62)
Could you please provide a test case? Simply attach the source of the compilation unit you are typing. I believe this is not the same issue than the original problem.
Created attachment 7611 [details] The source code that caused the ast creation error look at the line private Key key = new Key(); If the line is not complete I get the popup.
Reproduced the problem. I am investigating.
Created attachment 7629 [details] Reproducable test case Frederic, you can reproduce it by trying to parse this compilation unit. Simply add this test case in the ASTConverter2 tests: /** * http://dev.eclipse.org/bugs/show_bug.cgi?id=47396 */ public void test0536() throws JavaModelException { ICompilationUnit sourceUnit = getCompilationUnit("Converter", "src", "test0536", "A.java"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$ //$NON-NLS-4$ ASTNode result = runConversion(sourceUnit, false); assertNotNull("No compilation unit", result); } After putting the attached file in the source folder src/test0536.
*** Bug 50849 has been marked as a duplicate of this bug. ***
Fixed. Problem while recovering, ASTConverter.convert(Javadoc) may be called several times on same Javadoc. Before we created each times a new Javadoc, but know we reuse the same in the global list commentsTable of CU. So, before adding the javadoc to body declaration, verify that it has not already a parent... Test cases added in ASTConverterTest2 and ASTConverterJavadocTest
Question: what is special about the letter v that caused the problem?
I've no precise idea about this. My assumption is that jdt-ui at this peculiar moment has requested a build of DOM AST nodes hierarchy on Compilation Unit and then got the bug... But, I'm don't know jdt-ui code to be able to understand why it does it at this moment.
I don't like closing bugs under this situation. What is bothering me is that your explanation doesn't account for enough of the symptoms. At the very least, it should be determined why the bug is reached only under special situations. I did a little more testing under Integration 20040128 and the original file that I submitted. If I alter the line "private Key key = new Key();" 1) erase everything on the line except the word private - no error 2) erase everything on the line except part of the word private - error 3) erase everything on the line except the word private and Key - error 4) erase everything on the line except the word private and Key and some letters from key - no error This seems to be dependent on the ability of the parser to make sense of what it encounters. But only if the bad line is where it is. If the bad line is before the comment, no problem. I don't know if this is normal for the incremental parsing, but the question has to be asked.
> Question: what is special about the letter v that caused the problem? shmuel: The exact time of AST calculation is very timing and load dependent. jdt-ui calculates the AST in the background shortly after the user has stopped typing. So, nothing is special about the letter v, except if you stop typing after it ... The fix in comment 15 sounds reasonable and I'm sure Frédéric knows why it is fixed now, even if he didn't explain every detail about it.
I was not clear enough with my answer, when I said "I have no precise idea about this...", it was in fact to answer precisely to your question: why when I type "v" I got the error... I didn't really know why it's 'v' and not 'i' or 'a' as for compiler, in this case, there's no difference between 'pri' ,'priv' , 'priva', 'privat': there are all identifiers. 'private' is different as it's considered as a keyword and parse will go through a different way (it's clear with your different test as the error didn't occur when whole private is written)... In fact Markus really answer your question. Explanation was given when I set the bug to fix, perhaps not clear enough, but this explanation was more a reminder for me than an explanation for reporter...
Explanation accepted. Please note that I did not reopen the bug. I was merely asking for clarification. My intention was just to call attention to the fact that the error did not always occur. If there was something wrong in the parse logic, this was a good test case. By fixing the AST problem, you were masking the only visible manifestation of such a problem. My experience says that finding reproducible problems like this is 90% of the work, fixing them is 10%. I didn't want you to throw out something that is a good test case for another group. I understand from your response that you didn't. I'll drop the subject now.
Don't worry too much about the 'v'. I guessed that the AST creation happened after the user stopped typing. I simply created an example that a user can reach easily. 'v' as the beginning of 'void' :-).
Verified for 3.0M7
