[foreign] RFR: improved macro parser
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Jun 5 08:37:59 UTC 2018
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