Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump cel-spec + googleapi submodules #476

Merged
merged 3 commits into from
Nov 18, 2023

Conversation

snazy
Copy link
Member

@snazy snazy commented Nov 17, 2023

Bump cel-spec submodule to v0.13.0, googleapi submodule to f2d78630d2c1d5e20041dfff963e093de9298e4d.

This was necessary due to recent build errors caused by missing (old) artifacts for the conformance bazel build.

The submodule bumps bring a bunch of new conformance tests as well, which unveiled that some functionality that was not present in CEL-Go when CEL-Java was created, is required by the CEl-Spec.

Summary of changes:

  • Bugfix in o.p.c.checker.Standard that fixes a type resolution error for equals and not-equals functions, when both parameters need to be up-casted.
  • Changes in many types (in o.p.c.common.types.*T classes) to automatically convert between numeric and null types.
    • equal and compare with a null and a non-null type no longer fail, but return False
    • equal and compare between different numeric types no longer fail, but return "the right" result
    • this includes that numeric CEL map keys can be heterogenous, e.g. an int can be retrieved using an uint or double key
  • Fix retrieval of milliseconds from Duration - must only return the milliseconds within the second
  • Un-ignore a bunch of conformance tests that pass fine now

A few conformance tests have been added to InterpreterTest, but the majority of tests is left in the conformance tests.

* add `compileAll` task
* add IntelliJ-sync-task
* bump jandex version to make it work with Java 21
@snazy snazy force-pushed the bump-cel-spec-googleapis branch 3 times, most recently from da8d5c9 to a46e549 Compare November 17, 2023 13:54
Bump cel-spec submodule to [v0.13.0](https://github.com/google/cel-spec/releases/tag/v0.13.0), googleapi submodule to
[f2d78630d2c1d5e20041dfff963e093de9298e4d](googleapis/googleapis@f2d7863).

This was necessary due to recent build errors caused by missing (old) artifacts for the conformance bazel build.

The submodule bumps bring a bunch of new conformance tests as well, which unveiled that some functionality that was not present in CEL-Go when CEL-Java was created, is required by the CEl-Spec.

Summary of changes:
* Bugfix in `o.p.c.checker.Standard` that fixes a type resolution error for equals and not-equals functions, when both parameters need to be up-casted.
* Changes in many types (in `o.p.c.common.types.*T` classes) to automatically convert between numeric and null types.
  * equal and compare with a null and a non-null type no longer fail, but return `False`
  * equal and compare between different numeric types no longer fail, but return "the right" result
  * this includes that numeric CEL map keys can be heterogenous, e.g. an `int` can be retrieved using an `uint` or `double` key
* Fix retrieval of milliseconds from `Duration` - must only return the milliseconds within the second
* Un-ignore a bunch of conformance tests that pass fine now

A few conformance tests have been added to `InterpreterTest`, but the majority of tests is left in the conformance tests.
@snazy snazy force-pushed the bump-cel-spec-googleapis branch 2 times, most recently from a71269c to 5a815f7 Compare November 17, 2023 16:06
@@ -58,6 +61,10 @@ configure<ProtobufExtension> {
// Download from repositories
artifact = "com.google.protobuf:protoc:${libs.versions.protobuf.get()}"
}
plugins {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The conformance-tests proto/gRPC definitions have been moved in the googleapis repo - finally separated. This includes a change in the package names in the related classes.

@@ -162,13 +162,13 @@ Overloads.GreaterEqualsBytes, asList(Decls.Bytes, Decls.Bytes), Decls.Bool),
Decls.newFunction(
Operator.Equals.id,
Decls.newParameterizedOverload(
Overloads.Equals, asList(paramA, paramA), Decls.Bool, typeParamAList)));
Overloads.Equals, asList(paramA, paramB), Decls.Bool, typeParamABList)));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixes automatic up-casts for expressions like list(string) == list(double), which is translated a call to equals(list(string), list(double)), but before this change the (general) parameter type definition for A would have been memoized for the 2nd parameter as well, resulting in a "no such overload" error.

@@ -299,8 +313,6 @@ public static Val timeGetSeconds(Duration duration) {
}

public static Val timeGetMilliseconds(Duration duration) {
return IntT.intOf(
TimeUnit.SECONDS.toMillis(duration.getSeconds())
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was according to the CEL-Go implementation, but the conformance-tests proved it wrong.

@@ -282,6 +313,19 @@ public Val negate() {
}
}

/** Add implements traits.Adder.Add. */
@Override
public Val add(Val other) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No change, only moved to the related function.

@@ -228,6 +278,19 @@ public Val multiply(Val other) {
}
}

/** Add implements traits.Adder.Add. */
@Override
public Val add(Val other) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No change, only moved to the related function.

@snazy snazy marked this pull request as ready for review November 17, 2023 16:06
@snazy snazy requested a review from dimas-b November 17, 2023 16:06
// the OTHER uint is > Integer.MAX_VALUE, so THIS int MUST be smaller
return IntNegOne;
}
return intOfCompare(Long.compareUnsigned(i, other.intValue()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: At this point the values are within the [0; Integer.MAX_VALUE] range... Do we really need to use Long.compareUnsigned()?

@snazy snazy merged commit d9c5a6d into projectnessie:main Nov 18, 2023
4 checks passed
@snazy snazy deleted the bump-cel-spec-googleapis branch November 18, 2023 11:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants