Namespace for inner classes in jextract

[Samuel Audet]

Hi, Maurizio,

If you're looking for more inspiration in that direction, let me remind 
you of this page for JavaCPP containing what we found works well enough:
https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes

Samuel

On 3/12/21 12:05 AM, Maurizio Cimadamore wrote:
> Interesting - I was looking at the documentation of Rust's bindgen - 
> which provides an option to "blocklist" a symbol:
> 
> https://rust-lang.github.io/rust-bindgen/blocklisting.html
> 
> Turns out, there is a real sue case for generating everything but leave 
> out some bits (even if those bits are referred by other symbols) - and 
> that is to allow clients to define "their own version" of a given binding.
> 
> This is an interesting observation, which I think moves the design space 
> towards a "warn but generate" solution (rather than to avoid generating 
> symbols that depend on the symbol that is not imported).
> 
> As a validation, I also looked at other bindgen options, such as 
> allowlisting:
> 
> https://rust-lang.github.io/rust-bindgen/allowlisting.html
> 
> Which works similarly to what the proposed --sym does - except that it 
> also pulls in all the dependencies. This seems a bit redundant - that 
> is, if a client of jextract wants to be in 100% control of what gets 
> generated and opts for --sym, then, instead of having an option for 
> excluding a symbol, I think it's better to simply emit the --sym. Of 
> course there might be cases where the users want to extract things as 
> normal (e.g. no --sym), _except for a specific type_ - but I think 
> saying that, if you have this requirement, you fall in the "advanced 
> filtering bucket" is likely to be a good 80/20 approximation.
> 
> As expected and noted in one of my previous emails, allowlisting 
> unsurprisingly allows for different kind of symbols to be included 
> (functions, types and vars). I think the reality of the messiness of C's 
> namespace makes this probably a must (we have already seen enough cases 
> of "struct has same name as function" etc. - but I might be suffering 
> from name clash PTSD :-) ).
> 
> Maurizio
> 
> 
> 
> On 11/03/2021 14:26, Maurizio Cimadamore wrote:
>> And, (as I'm recalling all the things we went through with previous 
>> incarnation of similar ideas) - dependencies.
>>
>> you could have:
>>
>> typedef struct Foo Bar;
>>
>> What happens if you --sym Bar but not Foo?
>>
>> Previously, we had some dependency tracking system which tried to pull 
>> in as many symbols as required (e.g. if you wanted function "baz" it 
>> will pull in all stuff required by "baz" so that the binding would be 
>> correct). This is theoretically possible, but adds a lot of complexity 
>> to how jextract works.
>>
>> At the very least we would need to allow parsing the header into the 
>> intermediate IR, with some "dummy" nodes corresponding to the symbols 
>> that are not wanted - and then later on, do a pass to prune the IR so 
>> that any node that depends, directly or indirectly on a pruned symbol 
>> is removed too (and a warning printed about what's happening).
>>
>> Maurizio
>>
>> On 11/03/2021 13:55, Duncan Gittins wrote:
>>> On 11/03/2021 12:19, Maurizio Cimadamore wrote:
>>>>
>>>> On 11/03/2021 10:01, Duncan Gittins wrote:
>>>>> In my view all that is missing is command line options for multiple 
>>>>> "--sym symbol_to_keep" to a pick name to keep in the generation 
>>>>> process, and "--writeconfig myconfig.new" to write current run 
>>>>> options to file (for editing / split / re-submit) => a neat 
>>>>> formatted list of all params used by jextract PLUS list of all 
>>>>> symbols in the run. 
>>>>
>>>> This is a simple and nice idea - but it doesn't deal with your 
>>>> desire to give custom names to extracted symbols (which you brought 
>>>> up earlier).
>>>
>>> The filter improvement / --sym equivalent is a "must" because the 
>>> effect of not doing it is immediately noticable by a larger 
>>> proportion of those developers that try out jextract on Windows headers.
>>>
>>> Whereas the need for custom names of duplicate case-switched types 
>>> affects a small proportion of cases, so I'd rate it as "should/could" 
>>> (not essential in first release). There is a workaround for such 
>>> rarer cases by inlining the struct/layout into the application code 
>>> as raw foreign API calls - should the developer want to.
>>>
>>>> There's some validation to do when it comes to duplicate names - for 
>>>> instance, struct names can clash with typedef names, etc. which 
>>>> probably suggests that the syntax of the option will have to be more 
>>>> convoluted.
>>>
>>> Yes and no. It doesn't change the situation that is already present 
>>> with --filter for 2 headers that pulls out types with a clash, -sym 
>>> is just a finer degree of control of the in or out decision.
>>>
>>>>
>>>> Maurizio
>>>>