Bug #6594
open
Reflexive access to overloaded methods in Saxon 10 on .NET Framework
0%
Description
When attempting to call a non-static method using the clitype: mechanism in Saxon 10 on .NET Framework, if the method is overloaded (two methods on the class with the same number of arguments), Saxon rejects both overloads saying (in the -TJ trace output)
Arguments cannot be converted to required types
See https://saxonica.plan.io/boards/3/topics/9759?r=9788
The problem is that if the method reference is ambiguous, Saxon calls DotNetExtensionLibrary.getBestFit(), which assesses the suitablity of each of the supplied arguments, including the first, which should evaluate to an instance of the target class. But the test for this argument in getConversionPreference() is going to return -1, indicating that no conversion is possible. Specifically, the required type will be DotNetExternalObject, and getPrimitiveType() on this returns StandardNames.XS_ANY_ATOMIC_TYPE, for which there is no entry in the "switch" expression in getConversionPreference().
Although this is a significant bug, Saxon 10 on .NET Framework is a bit of a dead end, so the chances of producing a fix are fairly slender.
Updated by Michael Kay about 14 hours ago
Note also two other problems encountered during that investigation:
java.lang.UnsupportedOperationException at com.saxonica.expr.DotNetExtensionFunctionCall.copy(DotNetExtensionFunctionCall.java:188) That is indeed an unimplemented method in the Saxon class for calling extension functions, and the main thing it reveals is how thin the test coverage is on this feature, both before we release, and in the field.
Finding best fit method with arguments: java.lang.NullPointerException at net.sf.saxon.expr.Expression.getRetainedStaticContext(Expression.java:461) at net.sf.saxon.trace.ExpressionPresenter.startElement(ExpressionPresenter.java:302) at net.sf.saxon.expr.GlobalVariableReference.export(GlobalVariableReference.java:146) at com.saxonica.config.DotNetExtensionLibrary.getBestFit(DotNetExtensionLibrary.java:515) This is a problem in the -TJ diagnostic code, though it could also occur on other paths, for example using -explain or -export on a stylesheet that contains reflexive extension function calls.
Please register to edit this issue
.