[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