Change how and
and or
operations are compiled to IR to support custom values
#14653
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Because
and
andor
are short-circuiting operations in Nushell, they must be compiled to a sequence that avoids evaluating the RHS if the LHS is already sufficient to determine the output - i.e.,false
forand
andtrue
foror
. I initially implemented this withbranch-if
instructions, simply returning the RHS if it needed to be evaluated, and returning the short-circuited boolean value if it did not.Example for
$a and $b
:Unfortunately, this broke polars, because using
and
/or
on custom values is perfectly valid and they're allowed to define that behavior differently, and the polars plugin uses this for boolean masks. But without using thebinary-op
instruction, that custom behavior is never invoked. Additionally,branch-if
requires a boolean, and custom values are not booleans. This changes the IR to the following, using thematch
instruction to check for the specific short-circuit value instead, and still invokingbinary-op
otherwise:I've also renamed
Pattern::Value
toPattern::Expression
and added a properPattern::Value
variant that actually contains aValue
instead. I'm still hoping to removePattern::Expression
eventually, because it's kind of a hack - we don't actually evaluate the expression, we just match it against a few cases specifically for pattern matching, and it's one of the cases where AST leaks into IR and I want to remove all of those cases, because AST should not leak into IR.Fixes #14518
User-Facing Changes
and
andor
now support custom values again.match
is more complex.Tests + Formatting
The existing tests pass, but I didn't add anything new. Unfortunately I don't think there's anything built-in to trigger this, but maybe some testcases could be added to polars to test it.