[foreign] RFR: jextract generates duplicate macros

[Maurizio Cimadamore]

Looks good - better than what I had, thanks.

I'd suggest to replace the warning (produce called twice) with an 
assertion (IllegalStateException) since if that happens all bets are off.

Maurizio


On 19/06/18 23:32, Henry Jen wrote:
> I took your first revision and test from second, then only allow produce be called once as it should be, since the ClassWriter will be closed after the call. This also make sure NativeHeader won’t be generated twice, and allow jclang-ffi test to pass.
>
> The combined webrev can be found at
>
> http://cr.openjdk.java.net/~henryjen/panama/foreign/doubleProduce/webrev/
>
> Cheers,
> Henry
>
>> On Jun 19, 2018, at 10:54 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> Updated webrev - as per our offline discussion, there are still cases where macros are generated twice, namely when both -d and -o options are passed (in which case CodeFactory::collect is called twice).
>>
>> The new solution is to store defined macro in a queue inside AsmCodeFactory, and flush the queue on the first collect.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/duplicate_macros_v2/
>>
>> Maurizio
>>
>>
>> On 19/06/18 15:53, Henry Jen wrote:
>>> Looks good. This will make sure macro is only generated in the header file defines them.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>>> On Jun 19, 2018, at 3:43 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>> Hi,
>>>> the new macro parsing code has a bug, as sometimes the same macro constant can be added twice. This is due to a behavior that's there by design: macros are now collected within a given jextract context, since constants in header file A might depend on header file B, and so forth. This patch simply adds some filtering capabilities to the Context::macros method, to make sure that only macros that are relevant to a given file are returned.
>>>>
>>>> I also tweaked the code in HeaderFile::processCursor, to always process the contents of a macro, regardless of whether the file in question has an associated code factory or not. Note that the process by which we generate macros has two steps: first we collect all macros, then in a second step, the code factory asks the contexts all the macro relevant to that file and emits them. So, in the collection phase, we wanna make sure we collect every possible macro that could define a constant we might need to depend on later.
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/panama/duplicate_macros/
>>>>
>>>> Maurizio
>>>>