[Checkers] Augmenting Parser

[Benjamin Muskalla]

Hi Mahmood,

please see inline comments.

Mahmood Ali wrote:
> 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).
Yeah i already played around with the grammer successfully but I think 
it would be great if you can share your changes so we can take a look at 
it instead of reinventing the wheel.
> 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.
As mentioned above it would be great if you can share it with others or 
even better provide a patch against current HEAD.

Greets
  Benny
>
>
> Regards,
> Mahmood
>


-- 
Benjamin Muskalla
Innoopract Informationssysteme GmbH
bmuskalla at innoopract.com 
http://www.innoopract.com
Tel: 0721 - 66 47 33 - 0
Fax: 0721 - 66 47 33 29 

Innoopract Informationssysteme GmbH
Stephanienstrasse 20, 76133 Karlsruhe Germany
General Manager: Jochen Krause 
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883

www.innoopract.com