Skip to content

fix: apply declared nullability from AnyType return type to resolved concrete type#205

Merged
benbellick merged 2 commits intosubstrait-io:mainfrom
moraistejerina:fix-anytype-declared-output-nullability
Mar 4, 2026
Merged

fix: apply declared nullability from AnyType return type to resolved concrete type#205
benbellick merged 2 commits intosubstrait-io:mainfrom
moraistejerina:fix-anytype-declared-output-nullability

Conversation

@moraistejerina
Copy link
Copy Markdown
Contributor

@moraistejerina moraistejerina commented Mar 4, 2026

Summary

Fix AnyType.ReturnType() to apply the declared nullability (? suffix) from the return type definition to the resolved concrete type.

Fixes substrait-io/substrait#943

Problem

When a function declares a nullable return type like any1? (e.g., nullif with nullability: DECLARED_OUTPUT as introduced in substrait spec v0.81.0), the ? nullability is correctly parsed and stored in AnyType.Nullability, but ReturnType() never applies it to the resolved concrete type.

unwrapAnyTypeWithName() returns the matching argument type as-is, discarding the declared nullability. For example:

# From functions_comparison.yaml (substrait spec v0.81.0)
- name: "nullif"
  impls:
    - args:
        - value: any1
        - value: any1
      return: any1?
      nullability: DECLARED_OUTPUT

Calling nullif(string NOT NULL, string NOT NULL) produces string NOT NULL as the return type, instead of the expected string NULL — because NULLIF can always return NULL when both arguments are equal.

Fix

In AnyType.ReturnType(), after resolving the concrete type via unwrapAnyTypeWithName, apply the AnyType's declared nullability when it is nullable:

if m.Nullability == NullabilityNullable {
    typ = typ.WithNullability(NullabilityNullable)
}

Tests

  • Added new test case in extensions/variants_test.go: nullif(any1, any1) -> any1? [DECLARED_OUTPUT] — verifies non-nullable arguments still produce nullable output when the function declares return: any1?
  • Updated 2 existing test cases in types/any_type_test.go (any, anyOtherName) whose expected results now correctly reflect nullable output when the AnyType declares ?
  • Full test suite passes: go test ./...

…concrete type

When a function declares a nullable return type like `any1?` (e.g.,
`nullif` with `nullability: DECLARED_OUTPUT`), the `?` nullability was
parsed and stored in the `AnyType.Nullability` field but never applied
to the concrete type resolved by `ReturnType()`.

`unwrapAnyTypeWithName` returns the matching argument type as-is,
discarding the declared nullability. For example, `nullif(string, string)`
with return type `any1?` would produce a non-nullable `string` output
instead of the expected nullable `string?`.

This caused downstream consumers (e.g., Calcite-based optimizers) to
incorrectly treat NULLIF results as non-nullable, leading to the
elimination of enclosing COALESCE calls that depended on NULLIF's
potential NULL output.

The fix applies the AnyType's declared nullability to the resolved
concrete type in `ReturnType()` when the AnyType is nullable.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown
Member

@benbellick benbellick left a comment

Choose a reason for hiding this comment

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

Just the one comment about how DECLARED_OUTPUT interacts with the nullability-required case. Thanks!

Comment thread types/any_type.go
@codecov
Copy link
Copy Markdown

codecov Bot commented Mar 4, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.24%. Comparing base (8179602) to head (fbc7fec).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #205   +/-   ##
=======================================
  Coverage   68.23%   68.24%           
=======================================
  Files          47       47           
  Lines       10711    10713    +2     
=======================================
+ Hits         7309     7311    +2     
  Misses       3046     3046           
  Partials      356      356           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment thread types/any_type.go
@benbellick benbellick self-requested a review March 4, 2026 18:39
Copy link
Copy Markdown
Member

@benbellick benbellick left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@benbellick benbellick changed the title fix: apply declared nullability from AnyType return type to resolved concrete type fix: apply declared nullability from AnyType return type to resolved concrete type in DELCARED_OUTPUT case Mar 4, 2026
@benbellick benbellick changed the title fix: apply declared nullability from AnyType return type to resolved concrete type in DELCARED_OUTPUT case fix: apply declared nullability from AnyType return type to resolved concrete type Mar 4, 2026
@benbellick benbellick merged commit 08aedc9 into substrait-io:main Mar 4, 2026
8 checks passed
@benbellick
Copy link
Copy Markdown
Member

For those coming back to this in the future, this did not close substrait-io/substrait#943. That was a mistake. That issues is still being resolved upstream.

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.

Clarify whether any[\d] type parameters can bind arguments with differing outermost nullability

3 participants