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

[Jorn Vernee]

> 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.

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