[foreign] RFR: improved macro parser

Sundararajan Athijegannathan sundararajan.athijegannathan at oracle.com
Tue Jun 5 08:40:30 UTC 2018


instance var in context seems better.

-Sundar

On 05/06/18, 2:07 PM, Maurizio Cimadamore wrote:
> Possibly - one alternative is to use a context-wide jshell instance - 
> the point is that same jshell needs to be shared across different 
> headers being evaluated during a run (as there could be references to 
> macros defined in dependent headers).
>
> Maurizio
>
>
> On 04/06/18 03:44, Sundararajan Athijegannathan wrote:
>> "static JShell" instance is used in MacroParser. I think jextract 
>> implements ToolProvider. If we create more than one jextract tool 
>> instance & use it, will it be a problem?
>>
>> -Sundar
>>
>> On 02/06/18, 2:51 AM, 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
>>>
>>>
>>>
>


More information about the panama-dev mailing list