[nicl] RFR: Support UnexposedDecl

[Henry Jen]

> On May 23, 2018, at 1:37 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Looks sensible.
> 
> Another, more implicit way to get there would be to enable this behavior only inside ' extern "C" ' blocks. E.g. teach jextract about the usual dance, and change interpretation for prototype-less function inside those boundaries. (and maybe have a flag that allows for overriding this kind of inference).
> 

We only see extern “C” in C++ mode, not in regular C mode in the way we use libclang.

I’ll push the current webrev if there is no objection and then we can think of the switch or other proposal make more sense to developers.

Cheers,
Henry

> Maurizio
> 
> 
> On 23/05/18 05:08, Henry Jen wrote:
>> Hi,
>> 
>> C allows K&R style function declaration, although is obsolete. Such declaration is considered non-prototype function declaration. Compile with -Wstrict-prototypes in clang will emit warnings.
>> 
>> However, many C++ code when providing C binding will use this form instead of int func(void) because that’s exactly what it should be in C++ and -Wstrict-prototypes for C is off by default.
>> 
>> So, consider following C header file which is actually quite often from C++ developer, who may consider writing int func(void) redundant,
>> 
>> #ifdef __cplusplus
>> extern “C” {
>> #endif
>> 
>> int func();
>> 
>> #ifdef __cplusplus
>> }
>> #endif
>> 
>> jextract will need to deal with that situation. With proposed webrev[1], developer can run jextract with C++ mode by passing ‘-C -x -C c++’, this is essential forcing libclang to parse header using c++ syntax. This is not too bad as eventually we will support c++, but there could be unexpected side-effects as jextract cannot deal with all c++ syntax yet. However, this is no worse than using jextract against a .hpp file.
>> 
>> When running in c++ mode, the extern “C” would be a UnexposedDecl, the webrev add support for that.
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/panama/namespace/webrev/
>> 
>> I would like to propose additional follow up by adding a switch —noKR(name is up to discussion). Developer can use that switch if he is certain the header file is not using K&R style prototype. In this case, we simply consider all non-prototype function declaration as no argument function prototype. Then we still parsing use C mode which should be less surprising. What do you think?
>> 
>> The change is made for nicl branch, I will port into foreign branch later with a couple other fixes for nicl in queue.
>> 
>> Cheers,
>> Henry
>> 
>