[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