Community
Participate
Working Groups
ASTs before JLS8 must not try to create nodes that are only allowed in JLS8. Hint: Open a call hierarchy on ASTNode#unsupportedIn2_3_4() and make sure all accesses are properly protected. You may want to set "Search Scope > Project" in the view menu. E.g. LambdaExpression nodes: package jsr335; public class RunnableTest { Runnable r = () -> System.out.println("hi"); } java.lang.UnsupportedOperationException: Operation only supported in JLS8 and later AST at org.eclipse.jdt.core.dom.ASTNode.unsupportedIn2_3_4(ASTNode.java:1906) at org.eclipse.jdt.core.dom.LambdaExpression.<init>(LambdaExpression.java:127) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2144) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1724) at org.eclipse.jdt.core.dom.ASTConverter.convertToVariableDeclarationFragment(ASTConverter.java:3137) at org.eclipse.jdt.core.dom.ASTConverter.convertToFieldDeclaration(ASTConverter.java:3026) at org.eclipse.jdt.core.dom.ASTConverter.checkAndAddMultipleFieldDeclaration(ASTConverter.java:417) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:183) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2809) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1329) at org.eclipse.jdt.core.dom.CompilationUnitResolver.convert(CompilationUnitResolver.java:295) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1212) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:812)
Please follow up asap. TIA. I don't see a check for AST level in org.eclipse.jdt.core.dom.ASTConverter.convert(LambdaExpression). We should tag the tree as being MALFORMED for lower JLS levels.
For LambdaExpressions, figuring out the "containing context" node to flag as being malformed has some challenges. As is written, convert(Expression) does not get to know the parent node. (1) Now this method could be refactored to receive a parent node, but that looks like an overkill for basically tagging the AST as being broken. (there are many callers (70+ - while lambda expressions can legally occur in only a few of them, they can syntactically-legally occur in all of them) (2) ASTVisitor as is, does not have a notion of last visited node - so it can't also be used without extensive changes to find the parent node. I see two quick solutions: (1) A coarse grained flagging approach: where (a) convert(LE) would return null for level < JLS8 and (b) flag the closest method/type as being MALFORMED. (2) convert(LE) could return a NullLiteral node that is flagged as being MALFORMED. (2) is a bit unorthodox and so we are proceeding with (1) - the coarse grained flagging approach. Markus, any reason this won't be sufficient for clients ? The compiler would have generated a suitable IProblem anyway
(In reply to comment #2) I see two quick solutions: (1) > A coarse grained flagging approach: where (a) convert(LE) would return > null for level < JLS8 and (b) flag the closest method/type as being > MALFORMED. (2) convert(LE) could return a NullLiteral node that is flagged > as being MALFORMED. (2) is a bit unorthodox and so we are proceeding with > (1) - the coarse grained flagging approach. The approach 1 was tried, but found to affect multiple places by throwing NPE. So we will be going ahead with (2) and returning a NullLiteral (with source positions) for AST < JLS8.
(In reply to comment #3) > The approach 1 was tried, but found to affect multiple places by throwing > NPE. So we will be going ahead with (2) and returning a NullLiteral (with > source positions) for AST < JLS8. Please tag the closest method/type as being malformed - in addition for good measure also tag the manufactured NullLiteral as being malformed.
(In reply to comment #3) > (In reply to comment #2) > > I see two quick solutions: I have noticed that your replies have weird quoting. For example in comment#3 I would have expected to see > I see two quick solutions: instead of I see two quick solutions: when you do reply, doesn't bugzilla automatically do this for you ? It could lead to confusion in future for a reader.
(In reply to comment #5) > when you do reply, doesn't bugzilla automatically do this for you ? Unfortunately, IE doesn't do this for all the lines, while chrome and firefox does. > It could lead to confusion in future for a reader.
Created attachment 228459 [details] Proposed Patch
(In reply to comment #0) > ASTs before JLS8 must not try to create nodes that are only allowed in JLS8. > > Hint: Open a call hierarchy on ASTNode#unsupportedIn2_3_4() and make sure > all accesses are properly protected. You may want to set "Search Scope > > Project" in the view menu. Checking: was this step done ? Are we in the clear ?
(In reply to comment #8) > (In reply to comment #0) > > ASTs before JLS8 must not try to create nodes that are only allowed in JLS8. > > > > Hint: Open a call hierarchy on ASTNode#unsupportedIn2_3_4() and make sure > > all accesses are properly protected. You may want to set "Search Scope > > > Project" in the view menu. > > Checking: was this step done ? Are we in the clear ? Yes. Have checked all the cases except calls in tests. All the accesses are either protected with a level check directly or indirectly (in a call above or with a if based on level check) or the method is documented to throw unsupported exception (eg: ASTNode:newLambdaExpression). [Did n't check the tests since 1)the tests have to go through any of the above entry points and 2) tests would have given an exception if there was a case otherwise]
Fix and tests released here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=253db1ad159947db401a053aab34e948bedb1e92 Thanks Manoj.
