[Checkers] Augmenting Parser

[Mahmood Ali]

Greetings Benjamin,

I am pleased to see we are working on this.  I just wanted to add a  
couple of points to Mike's reply.

Benjamin Muskalla wrote:
> as regular contributor to JDT I have a great interest to have a better
> integration of the JSR 308 in the JDT compiler. I'd like to take a  
> look
> at some of the "bigger" problems next week to see in which direction
> such a JDT/Core fork would go.
I started working on the JDT plug-in awhile ago and abandoned it at  
the time due to time constraints.
Here is my experience so far, which hopefully would assist you in your  
analysis:

Overall notes:
- Needless to tell you, Eclipse JDT is decoupled fairly well.  Once  
you change the compiler itself, automatically, the editor uses it for  
error highlighting and other things.  I think that we would simply  
need to modify the compiler and change one piece in the UI to specify  
the source conformance level.  I wouldn't be surprised if the compiler  
exposes which source levels it supports somehow.
- Compiler.process(CompilationUnitDeclaration, int) directs the  
compiler tasks.

Minor notes:

Parsing (org.eclipse.jdt.internal.compiler.parser.Parser):

1. The parser (actually one method in the class) is a generated parser  
from a LALR(1) grammar file.  I succeeded in modifying the grammar and  
can provide it for you.  I would need to update it to recognize the  
new array syntax (i.e. annotations preceding brackets instead of  
within).
2. The method that gets generated from the parser delegates the  
actions (e.g. constructing the AST, checking version conformance, etc)  
to other methods.
3. Parser way of constructing the AST is a bit interesting.  I think  
that type annotations are to use intStack, intPtr, and expressionStack  
fields.

Type Resolution:
1. type resolution is done through Statement.resolve().  You would  
need to modify the type annotation parent AST tree to resolve them as  
well.
2. watch out a bit for ASTNode.resolveAnnotations().

Random notes:
- It's a bit un-intuitive that parameterized types  
'ParameterizedSingleTypeReference' is a subtype of  
'ArrayTypeReference' even it is not an array!.
- I may suggest that you make code generation a lower priority than  
the rest, namely parsing and type checking.

> I just had a quick glance at the current Eclipse plugin. As far as I  
> can
> see (without the source) is that you only add actions to the java
> projects to internally call the real compiler. So seems there is not
> much magic involved in the current approach.
This is very correct.  I have a copy of modified jdt.core that parses  
JSR 308 type annotations without type checking them.  I use mainly to  
supress the 'syntax invalid' highlight errors.

Regards,
Mahmood