Community
Participate
Working Groups
Created attachment 279266 [details] Sources which occur the bug Hi, stacktrace: Status ERROR: org.eclipse.jdt.core code=4 Exception occurred during compilation unit conversion: ----------------------------------- SOURCE BEGIN ------------------------------------- package test; public enum ServiceRegion { JAPAN(new java.lang.String[]{"440", "441"}) { }; public enum LoginType { public static final com.naver.linewebtoon.common.localization.ServiceRegion.LoginType EMAIL = null; } } ----------------------------------- SOURCE END ------------------------------------- java.lang.IllegalArgumentException Exception in thread "main" java.lang.IllegalArgumentException at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:2973) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1630) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:267) at org.eclipse.jdt.core.dom.ASTConverter.convertToEnumDeclaration(ASTConverter.java:3352) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:3050) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1438) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1064) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:662) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:1012) at test.Main2.main(Main2.java:35) Both sources are attached
Created attachment 279267 [details] Use it to build ASTs
*** Bug 178986 has been marked as a duplicate of this bug. ***
You are aware of the syntax errors in the sources, aren't you? Source positions in recovered AST is a very thorny issue.
> You are aware of the syntax errors in the sources, aren't you? Yes, I'm. But I'd like JDT not to crash :(
Another stack trace: java.lang.IllegalArgumentException at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:3008) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:645) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:205) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:3115) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1439) at org.eclipse.jdt.core.dom.AST.convertCompilationUnit(AST.java:392) at org.eclipse.jdt.internal.core.CompilationUnit.buildStructure(CompilationUnit.java:200) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:268) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:596) at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1138) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:173) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:736) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:802) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1315) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:131) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:113) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:93) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:90) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:157) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:92) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:107) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:76) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:210) My class does not have a syntax error (but did have one a couple of minutes ago).
@Sarika: Can you please take a look?
Bulk move out of 4.14
Currently when we try pasting this code, It doesn't create a compilation unit as the convert method did not succeed. There might be other issues for convert failure, but one option could be to just create a null source range and log an error? A compilation unit should have been created with compilation errors I guess. But will that be agreeable for the non UI oriented AST compilation as well? @Manoj, Jay! What are your thoughts ?
As Manoj and Jay are bus with Java 16 work, moving this out to 4.20.
Not able to proceed without further guidance.
@Sarika, were you saying you could reproduce the exception? If so, did you see the compiler AST? Can you tell us, where in the compiler AST source positions were broken? Or was the compiler AST just too broken to be usable by UI features?
Created attachment 286169 [details] Test Patch to reproduce (In reply to Stephan Herrmann from comment #11) > @Sarika, were you saying you could reproduce the exception? @Stephan/Sarika: the attached patch which is junit-ization (if I may :)) of the description gives the exception.
(In reply to Stephan Herrmann from comment #11) > If so, did you see the compiler AST? Can you tell us, where in the compiler > AST source positions were broken? Or was the compiler AST just too broken to > be usable by UI features? From debugging at DOM.ASTConvertor(), the source positions are broken for anonymoustype for the field initializer of enum. (In reply to Sarika Sinha from comment #8) > There might be other issues for convert failure, but one option could be to @Sarika: Other than source positions being broken, I don't see any other issues for the convert failure - Any particular issue in mind?
(In reply to Stephan Herrmann from comment #11) > @Sarika, were you saying you could reproduce the exception? > If so, did you see the compiler AST? Can you tell us, where in the compiler > AST source positions were broken? Or was the compiler AST just too broken to > be usable by UI features? Yes, by simply pasting the code from comment#0, can reproduce the exception and the java files are not created. (In reply to Manoj Palat from comment #13) > @Sarika: Other than source positions being broken, I don't see any other > issues for the convert failure - Any particular issue in mind? Yes, in this case the sourceEnd of QualifiedAllocationExpression is not provided by the compiler node. If that is fixed it will solve the immediate problem. My comment was for in general, should we stop the creation of compilation unit if there are source range issues?
(In reply to Sarika Sinha from comment #14) > > (In reply to Manoj Palat from comment #13) > > > @Sarika: Other than source positions being broken, I don't see any other > > issues for the convert failure - Any particular issue in mind? > > Yes, in this case the sourceEnd of QualifiedAllocationExpression is not > provided by the compiler node. If that is fixed it will solve the immediate > problem. > Well, that indeed was the comment :) - source positions (source start and source end) in a recovered ast is tricky - see comment 3) > My comment was for in general, should we stop the creation of compilation > unit if there are source range issues? From the compiler side, we should continue. However, from the dom side, it would be good to think about containing this error. Complete stop may not be a good idea. What about creating a null node only for the affected part - not null but something along the lines of ASTConverter.createFakeNullLiteral() only for those parts where the source positions are not good? just a suggestion.
(In reply to Manoj Palat from comment #15) > > From the compiler side, we should continue. However, from the dom side, it > would be good to think about containing this error. Complete stop may not be > a good idea. What about creating a null node only for the affected part - > not null but something along the lines of > ASTConverter.createFakeNullLiteral() only for those parts where the source > positions are not good? just a suggestion. As source range is simple int, we can add a wrapper method in ASTConverter to setSourceRange and incase of exception, we can set the startPosition as -1, length as 0 and set the Malformed flag for the node. WDYT?
(In reply to Sarika Sinha from comment #16) > As source range is simple int, we can add a wrapper method in ASTConverter > to setSourceRange and incase of exception, we can set the startPosition as > -1, length as 0 and set the Malformed flag for the node. > > WDYT? If you are creating something like FakeNullLiteral as suggested in comment 15, the MALFORMED should also be set - see ASTConverter.createFakeNullLiteral() which already does this. I assume what you are meaning is you don't want to create something like FakeNullLiteral, but reuse this existing node but set MALFORMED. Setting MALFORMED is expected anyway. Leaving the implementation part, the concern is about setting the source positions. You may want to check convertToVariableDeclarationFragment() in ASTConverter where a similar situation is handled. Initializing the node with -1,0 as default may not go down well with the clients who would expect the source positions of the child to be within the parent's source positions. For example, the debug run will give an ST. Also, you may want to check with DOM AST View which is a major client of this as to whether they are fine with this. my 2 cents...
Will try in 4.21.
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.
