[foreign] RFR: improved macro parser

[Maurizio Cimadamore]

I believe it's ok to share the file manager - we do this in several 
compiler regression tests to reduce some of the overhead associated when 
creating a file manager. Since we're not really using any file manager 
related option in the various tasks (e.g. -d etc.), there should be no 
leaking at all - e.g. all javac tasks should share same input/output 
paths, etc.

Maurizio


On 11/06/18 03:59, Sundararajan Athijegannathan wrote:
> * 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
>>>
>>>
>>>
>>