[foreign] RFR: improved macro parser

[Sundararajan Athijegannathan]

* Will the static JavaFileManager in MacroParser leak stuff? or is it 
okay to share it?
* constants.h misses copyright.

+1 other than that.

Thanks
-Sundar

On 07/06/18, 6:53 PM, Maurizio Cimadamore wrote:
> 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
>>
>>
>>
>