[enhancement] function type checks

[line-o]

Description:

BREAKING CHANGE

Internal module functions can now enforce function parameters to adhere to a given signature.

This is added to all HoFs fn:filter, fn:for-each, fn:fold-left, fn:fold-right as well
as their Array and Map function variants.

It is written such that other function values can also be checked array(xs:string) or complex ones like map(xs:integer, function(array(*)) as xs:boolean))

NOTE:

An implementation decision was, to still allow developers to write

filter(1, function ($a) { exists($a) })

instead of having to write

filter(1, function ($a) as xs:boolean { exists($a) })

For function parameters that return item()*, defer the return type check. Throw an error when the first non-matching result is returned.
This later check is currently done in the function implementation itself (see fn:filter).
A better alternative would be:

1. being able to distinguish between a function with no explicit types set and one that does state it would return item()*
2. only when types are not specified check the types at runtime.

Examples:

• fn:filter -> function (item()) as xs:boolean
• array:for-each-pair -> function (item()*, item()*) as item()*
• map:for-each -> function (xs:anyAtomicValue, item()*) as item()*

Basex seems to follow the same optimistic approach

Reference:

Result of discussion with @adamretter in #3364
Is related to #1917
supersedes #3361 (the expathrepo related commit will be added here)
fixes #3382
fixes #4596
fixes #6125
related #3370

Type of tests:

All tests pass, two where adapted to match correct behaviour.

[JoernT]

look good to me - very clean

[line-o]

Nine additional XQTS cases pass:

• fn-filter-015
• fn-filter-018
• filter-901
• filter-902
• fn-for-each-pair-037
• array-for-each-006
• array-for-each-pair-308
• array-filter-007
• array-filter-008

failing XQTS tests are due to

• [BUG] java classCastException on some built-ins with placeholder #4795 : d1e56387
• [BUG] fn:for-each rejects map and array items as $functions param #4596 : array-for-each-008, array-for-each-009, array-filter-011, array-filter-012
• problems in the XQTS runner : re-*

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
11 Code Smells

69.8% Coverage
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[joewiz]

As discussed in the Community Call, this PR helps with XQuery conformance, achieves 9 more passing XQTS tests that previously failed, provides better static checking, and lays the groundwork for additional type checking of function parameters and return values.

[adamretter]

I think this is a great start, and I am excited to see it. I do think it requires some work yet to complete it and polish it.

Apart from my specific code comments I am a bit confused by this statement in the PR description:

NOTE:
An implementation decision was, to still allow developers to write

filter(1, function ($a) { exists($a) })

instead of having to write

filter(1, function ($a) as xs:boolean { exists($a) })

Unless I am mistaken, that isn't a decision for an Implementation... It is actually required by the XQuery 3.1 specification, see: https://www.w3.org/TR/xquery-31/#prod-xquery31-InlineFunctionExpr

I am also not sure I understand this statement:

This later check is currently done in the function implementation itself (see fn:filter).

I understand that every function that accepts a function (as a parameter) will need its function signature modified to declare the additional parameter/return types, but
does that also mean that each of those also needs to be modified to perform the actual type checks of the function parameter's parameters? If so, it would seem that this checking should be moved out into something like the DynamicCardinalityCheck class.

[adamretter]

The cardinality parameter should follow the primaryType parameter, as they are part of the same sequence type. This is how it currently works in FunctionParameterSequenceType and that should be preserved here, as it makes the code for defining a FunctionSignature more logical to both write and read.

[dizzzz]

LGTM