[foreign] RFR 8210935 C enum constants should be mapped to interface methods instead of static final int constants

[Maurizio Cimadamore]

More on this; consider this test:

$ cat testLimits.h

#include <limits.h>

void f() { }


If I extract this I get an error:

$ jextract testLimits.h
/usr/include/limits.h:123:16: fatal error: 'limits.h' file not found
/usr/include/limits.h:123:16: fatal error: 'limits.h' file not found


With some more debugging sprinkled:

$ jextract -C-v testLimits.h
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
ignoring nonexistent directory "../lib/clang/4.0.1/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/include
  /usr/include/x86_64-linux-gnu
  /usr/include
End of search list.
/usr/include/limits.h:123:16: fatal error: 'limits.h' file not found
/usr/include/limits.h:123:16: fatal error: 'limits.h' file not found

So, /usr/include is there, but the problem is that it does some trick to 
include an additional limits.h header which is GCC-specific:

  /* Get the compiler's limits.h, which defines almost all the ISO 
constants.

     We put this #include_next outside the double inclusion check because
     it should be possible to include this file more than once and still get
     the definitions from gcc's header.  */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
/* `_GCC_LIMITS_H_' is what GCC's file defines.  */
# include_next <limits.h>
#endif

So, in order to use limits.h in my platform I have to resort to clang 
trickery - e.g.

$ jextract -C-U__GNUC__ testLimits.h

the above passes - but feels dirty (a lot).



My feeling is that clang's header should always be picked up in these 
cases - as those are the ones that get picked up if I do a standalone 
call to clang:

$ clang -M testLimits.h

testLimits.o: testLimits.h \
   /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include/limits.h \
   /usr/include/limits.h /usr/include/features.h \
   /usr/include/stdc-predef.h /usr/include/x86_64-linux-gnu/sys/cdefs.h \
   /usr/include/x86_64-linux-gnu/bits/wordsize.h \
   /usr/include/x86_64-linux-gnu/gnu/stubs.h \
   /usr/include/x86_64-linux-gnu/gnu/stubs-64.h \
   /usr/include/x86_64-linux-gnu/bits/posix1_lim.h \
   /usr/include/x86_64-linux-gnu/bits/local_lim.h \
   /usr/include/linux/limits.h \
   /usr/include/x86_64-linux-gnu/bits/posix2_lim.h

As you can see, it's getting LLVM limits.h; jextract should behave the same.

Maurizio

On 20/09/18 18:23, Maurizio Cimadamore wrote:
> I have an issue with this test when running on Linux:
>
> /usr/include/limits.h:123:16: fatal error: 'limits.h' file not found
> java.lang.RuntimeException: jextract returns non-zero value
>     at JtregJextract.jextract(JtregJextract.java:85)
>     at JtregJextract.main(JtregJextract.java:96)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>     at 
> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:229)
>     at java.base/java.lang.Thread.run(Thread.java:834)
>
> I think the culprit is that we are not copying the clang version of 
> limits.h into the JDK; from make/copy/Copy-jdk.jextract.gmk:
>
> JEXTRACT_SRC_FILES := $(wildcard $(JEXTRACT_CONF_SRC)/*std*.h)
>
> That is we are filtering with 'std'. I think we need limits.h too (and 
> possibly others).
>
> Maurizio
>
>
> On 20/09/18 18:16, Maurizio Cimadamore wrote:
>> Looks good!
>>
>> Maurizio
>>
>>
>> On 20/09/18 16:22, Sundararajan Athijegannathan wrote:
>>> Thanks. I've added few more tests to combine enum constants.
>>>
>>> Pushing this updated changes: 
>>> http://cr.openjdk.java.net/~sundar/8210935/webrev.01/
>>>
>>> -Sundar
>>>
>>> On 20/09/18, 8:26 PM, Maurizio Cimadamore wrote:
>>>> Looks good.
>>>>
>>>> Maybe in the test you could also check that e.g. combining enum 
>>>> constants in Java and C yields the same - e.g.
>>>>
>>>> R | G
>>>>
>>>> ?
>>>>
>>>> Maurizio
>>>>
>>>>
>>>>
>>>> On 20/09/18 06:15, Sundararajan Athijegannathan wrote:
>>>>> Please review.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210935
>>>>> Webrev: http://cr.openjdk.java.net/~sundar/8210935/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> -Sundar
>>>>
>>
>