RFR: 7903656: Variadic invoker class names are not mangled
Maurizio Cimadamore
mcimadamore at openjdk.org
Fri Feb 9 09:40:09 UTC 2024
On Fri, 9 Feb 2024 08:51:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
> This PR fixes an issue with the variadic invoker nested class names that are not mangled correctly. This might create issues for case-insensitive file systems.
>
> While working on this, I noticed also that the current test we have for variadic classes (TestPrintf) was not executing as expected, because of a typo in a data provider. After fixing the test code, the test started to fail.
>
> One of the test cases was expecting an `IllegalArgumentException` when passing an int value to a double variadic parameter. But, as we use a method handle argument spreader, no exception is throw, and the value is instead silently converted. I tweaked the test a bit, to create a situation where no conversion is possible, and I noticed that the call failed with `ClassCastException`, but that exception is not handled by the variadic invoker code, so I fixed that as well.
For the records, emitting nested classes with non-mangled names can be a bit problematic - consider this case:
//foo.java
int m(int n, ...);
struct m {
int x;
};
And, the following Java code:
import static test.foo_h.*;
m.invoke(42);
This call is deemed to be ambiguous by javac:
java: reference to m is ambiguous
both interface test.foo_h.m in test.foo_h and class test.m in test match
Because of the `import static`, `f` can mean two different classes: the toplevel struct class, or the nested variadic one.
I don't think this is a big issue (the class reference can be disambiguated with a qualifier), but I wanted to record it here, just in case. Perhaps this is a sign that `NameMangler` should be enhanced to deal with all the nested class names that we know are going to be generated inside the header class (e.g. as opposed to using some local name mangling logic in HeaderFileBuilder).
-------------
PR Comment: https://git.openjdk.org/jextract/pull/203#issuecomment-1935602924
More information about the jextract-dev
mailing list