Fix short circuit evaluation of AND / OR in the Turbopack analyzer for string & nullish-related methods#94159
Conversation
`is_string`, `is_empty_string`, and `is_nullish`'s short circuit evaluation of `&&` and `||` was reversed. Fixes them + adds unit tests.
Tests PassedCommit: 4dc9ef9 |
Stats skippedCommit: 4dc9ef9 |
bgw
left a comment
There was a problem hiding this comment.
- We use rstest to create parameterized tests in a few places. It would be good to pull that in and use it here. https://docs.rs/rstest/latest/rstest/#creating-parametrized-tests
- Claude loves generating a bazillion unit tests. We probably don't need to be quite this exhaustive. See if it makes sense to trim down a few of the test cases.
Neat - switched over to these!
Oops, that was just me copy-pasting and making slight changes to each one. I trimmed it down to four per method (one true for AND, one true for OR, one false for AND, and one false for OR). |
| #[rstest] | ||
| #[case("'hello' && 2", false)] | ||
| #[case("1 && 'hello'", true)] | ||
| #[case("'hello' || 'bye' || 2", true)] | ||
| #[case("2 || 1 || 'hello' || 'bye'", false)] | ||
| fn is_string_short_circuiting(#[case] input: &str, #[case] expected: bool) { |
There was a problem hiding this comment.
add some none results for cases we cannot analyze
this should be as simple as referencing unbound variables in the expression x && 2
also i find the true false parameters don't generate good error messages, so it might be better to split this into multiple test functions
fn is_string_short_circuiting_positive(#[case] input: &str) {
assert_eq!(EvalContext::eval_single_expr_lit(&input.into())
.unwrap()
.is_string(), Some(true), "expected '{}' to be a string", input)
}
ditto for negative and unknown
There was a problem hiding this comment.
Oh cool, didn't think of the none case! Added it + split up the tests.
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
lukesandberg
left a comment
There was a problem hiding this comment.
this looks good, though vade has a solid comment and i think there are a few more cases to handle for unknown
Also add a little bit of coverage for longer examples?
Co-authored-by: Luke Sandberg <lukesandberg@users.noreply.github.com>
Here is the original description of the bug:
As mentioned, in the issue
is_string,is_empty_string, andis_nullish's short circuit evaluation of&&and||was reversed. This PR reverses them so that for AND expressions, the first false-y value is evaluated (otherwise the last value is). For OR expressions, the first truth-y value is evaluated (otherwise the last value is).I’ve added unit tests to this PR. To verify these unit tests with JavaScript’s behaviour I used Claude Code to generate this node script:
After running it on my machine: