[Checkers] Augmenting Parser
mahmood at MIT.EDU
Thu Oct 2 00:48:36 EDT 2008
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
> 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
- 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
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
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
1. type resolution is done through Statement.resolve(). You would
need to modify the type annotation parent AST tree to resolve them as
2. watch out a bit for ASTNode.resolveAnnotations().
- 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
> 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.
More information about the checkers