[foreign] RFR: improved macro parser

[Maurizio Cimadamore]

Hi,
please find a second revision of the parser. This has a quite different 
design, and I've ditched use of jshell API in favor of a more direct 
approach using compiler API. The reason is that jshell API doesn't 
expose ASTs, so it is hard to filter out stuff we don't want - which 
means we can accidentally pull in Java constants (e.g. Integer.MAX_VALUE).

The new approach is much more straightforward (and faster too, since 
bits are not executed). It leans heavily on javac's constant folding - 
so macro are expanded, and given to the compiler which type-checks them; 
if all is a constant, javac will set the constant value on the variable 
- which is then accessible through the VariableElement API. If it's not 
constant, we should not bother with it in the first place.

A small visitor makes sure that we can only accept the right kind of 
trees - e.g. unary/binary expessions, parenthesis, literals.

The parser is using an internal API point - namely JavacTaskPool, which 
is used to share compilation context among multiple runs, and greatly 
speed up the type-checking machinery (otherwise we have to init the 
symbol tables at every macro evaluation, which is very costly). This is 
a standard trick we do in both compiler combo tests and jshell.

Webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/macro_parser_v2/

Cheers
Maurizio


On 01/06/18 22:21, Maurizio Cimadamore wrote:
> Hi,
> this webrev adds a new way of parsing object-like macros which relies 
> on the jshell API; defined macros are turned into jshell var 
> declaration - e.g.
>
> #define FOO 12
>
> is turned into
>
> 'var FOO = 12;'
>
> All macros are entered into a jshell context, and this allows to 
> 'resolve' macro names so that we can handle common cases like:
>
> #define MAX 43
> #define MIN (-MAX)
>
> Thanks to the jshell API the new code is not too complex, and it 
> handles the vast majority of constant-like macros. Of course we need a 
> more general fallback for macros (esp. function-like), e.g. I'm under 
> no illusion that this will work in all cases, but this looks like a 
> good improvement over the current strategy that blows up as soon as 
> there are more than two tokens in the macro.
>
> I tested with a bunch of system headers and results seemed 
> significantly better than before.
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/macro_parser/
>
> Maurizio
>
>
>