Community
Participate
Working Groups
20021010 The code contains a problem: The method is marked abstract but also has a body public class A { public abstract void foo() { return; } } Create the AST and get the MethodDeclaration. MethodDeclaration.getBody returns null! The AST should better not care about a such a semantic error and contain the body.
It might be more suttle than this. I think the parser is getting rid of the method body. In this case we could report a syntax error according to the JLS. We changed it to parse the source, but I need to find out what the limitations are. I am not sure I can retrieve the body. I will investigate. BTW it is not a semantic error, litteraly it is a syntax error.
The parser doesn't provide the statements in this case. It considers that there is nothing to parse in case of an abstract method. I will try to see what needs to be change to get the body. It might have side-effect in the compiler.
There is no way to get the body for an abstract method. The problem is that the parser has no way to distinguish between a "real" abstract method (without a body) and a "fake" abstract method like in your test case. The DOM/AST is supposed to return a tree that matches the source only if the code contains no error. OK to close as WONTFIX?
dirk, what do you think?
for me ok to close.
Just to clarify: the AST is supposed to match the code if the compilation doesn't contain any structual errors (missing bracket, body after abstract keyword, ...). It will match the compilation unit in all other cases like binding problems, same method defined twice, ...
Dirk, you're right. If a problem is a syntax error, the parser can feel free not to return the whole CU. Having an abstract modifier with a method body is a syntax error. We don't actually fail in the parser, but we don't propagate the method body. In cases with two identical methods, the tree matches the source, but no binding are available for both methods. Closed as WONTFIX.
Changed milestone.
The method foo() has a binding which doesn't contain ABSTRACT as one of its identifier. This is a consequence of bug 24773.
This method now contains a body even if the body is empty. There is no way to retrieve its statements.
When we perform our dual parse, if any error is detected on the method signature, then we will not parse its statements. This behavior can be changed, but maybe a little risky at this stage. Proposed fix is to comment out the following statements in: MethodDeclaration#parseStatements(Parser, CompilationUnitDeclaration) // if (ignoreFurtherInvestigation) // return; and similar change in ConstructorDeclaration.
A bit risky at this stage. Post 3.0
When testing the change (along with commenting out abstract/native check in actual Parser#parse(MethodDeclaration,...)), I am getting a syntax error which is a bit unexpected (error no.1 below). public class X { public abstract void foo( System.out.println() =; } } ---------- 1. ERROR in ...\X.java (at line 2) public abstract void foo( System.out.println() =; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax error on token(s), misplaced construct(s) ---------- 2. ERROR in ...\X.java (at line 2) public abstract void foo( ^^^^ Abstract methods do not specify a body ---------- 3. ERROR in ...\X.java (at line 2) public abstract void foo( ^^^^ The abstract method foo in type X can only be defined by an abstract class ---------- 4. ERROR in ...\X.java (at line 3) System.out.println() =; ^ Syntax error on token "=", { expected ---------- Need to be more investigated
Reassigned to David, post 3.0
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
