[foreign] RFR 8220544: Jextract; library dependent header filtering

[Maurizio Cimadamore]

On 13/03/2019 21:36, Jorn Vernee wrote:
>> Good questions. When no filter patterns are specified that is the case
>> everything is outputted, but when filter patterns are specified
>> headers are only added to the root set if they contain a symbol that
>> passes the filter.
>
> FWIW, basically headers with symbols that pass both types of filter 
> are added to the root set. There's 1.) Filtereing based on whether a 
> symbol is found in a library, and 2.) based on the used filter 
> patterns (--include-symbols & --exclude-symbols). I thought it would 
> be better to exclude a header from the root set if all the symbols in 
> it were filtered out by the filter patterns.

Yep - I think that sounds sensible

Maurizio

>
> Jorn
>
> Jorn Vernee schreef op 2019-03-13 22:30:
>> Maurizio Cimadamore schreef op 2019-03-13 22:08:
>>> Hi Jorn,
>>> this looks very good indeed. I'd like to play with it a bit before we
>>> go ahead with this, if that's ok.
>>
>> Please do!
>>
>>> Also, one question: if the user does not specify "-l" what happens? I
>>> guess the root set will then contain all the headers and we just get
>>> back the full output (which would be ok) ?
>>
>> Good questions. When no filter patterns are specified that is the case
>> everything is outputted, but when filter patterns are specified
>> headers are only added to the root set if they contain a symbol that
>> passes the filter.
>>
>> Maybe we should just fall back to 'include-everything' when no "-l"
>> options are specified, regardless of filter?
>>
>> Jorn
>>
>>> Maurizio
>>>
>>> On 13/03/2019 18:06, Jorn Vernee wrote:
>>>> Updated webrev: 
>>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8220544/webrev.01/
>>>>
>>>> Fixed the bug, also added tests & ran all the examples again to try 
>>>> and find other bugs (nothing found).
>>>>
>>>> Thanks,
>>>> Jorn
>>>>
>>>> Jorn Vernee schreef op 2019-03-13 17:50:
>>>>> Discovered a bug in this after posting :(
>>>>>
>>>>> DependencyFinder also needs to look for pointee and array element 
>>>>> type
>>>>> cursors (which it currently doesn't). I've tested a working fix, but
>>>>> will also add some tests for the particular cases. Updated webrev
>>>>> coming soon™
>>>>>
>>>>> Jorn
>>>>>
>>>>> Jorn Vernee schreef op 2019-03-13 17:21:
>>>>>> Hi,
>>>>>>
>>>>>> After some discussion:
>>>>>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-March/004828.html 
>>>>>> I've implemented the discussed approach to header & declaration 
>>>>>> filtering.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220544
>>>>>> Webrev: 
>>>>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8220544/webrev.00/ 
>>>>>>
>>>>>>
>>>>>> There are a few new implementation classes:
>>>>>>   * PattertnFilter; a helper class that encapsulates the Pattern 
>>>>>> based
>>>>>> filtering code previously found in SymbolFilter. This code had to be
>>>>>> reused.
>>>>>>   * Filters; a Context sub-component holding PatternFilters for
>>>>>> different types of declarations.
>>>>>>   * DependencyFinder; finds dependencies of the root set of
>>>>>> declarations found in the root headers.
>>>>>>   * ElementFilter; filters out non-library symbol elements based on
>>>>>> whether they appear in a root header or are required by something
>>>>>> therein.
>>>>>>   * RootSet; a helper class for managing root headers + required 
>>>>>> element Trees.
>>>>>>
>>>>>> I also encountered some crashes when debug printing Trees, which 
>>>>>> I've
>>>>>> fixed/worked around accordingly.
>>>>>>
>>>>>> FWIW, I tried this out with the Windows registry API and it's 
>>>>>> working
>>>>>> very nicely! Going from well over 100 headers to under 10. Some room
>>>>>> for improvement still exists; some empty headers and static 
>>>>>> forwarders
>>>>>> could still be omitted, but imho that should be handled by a 
>>>>>> separate
>>>>>> patch.
>>>>>>
>>>>>> Thanks,
>>>>>> Jorn