-
-
Notifications
You must be signed in to change notification settings - Fork 504
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
ast: ContentEq for -0
vs +0
#8982
Comments
Should That's a question, not an argument! We can adapt |
Our minifier folds unary numbers, oxc/crates/oxc_minifier/src/peephole/normalize.rs Lines 186 to 196 in 8eccdec
|
Fixes #8982. Previously `0f64.content_eq(-0f64)` returned `true`. Now it returns `false`. This also affects the behavior for `NaN`. Previously `f64::NAN.content_eq(f64::NAN)` returned `false`. Now it returns `true`. But it's complicated: ```rs f64::NAN.content_eq(f64::NAN) == true f64::NAN.content_eq(-f64::NAN) == false f64::NAN.content_eq(--f64::NAN) == true ``` This does *not* align with JS's `Object.is` which returns `true` for *any* two `NaN` values. If this matters, we could instead implement `f64::content_eq` as: ```rs if self.is_nan() && other.is_nan() { true } else { self.to_bits() == other.to_bits() } ``` But this generates quite a lot of assembly for all `f64` values, just to cover this small edge case with `NaN`: https://godbolt.org/z/q9zYodn4e So I suggest that we go with it as in this PR for now, and see if `NaN` causes us problems in reality or not.
Fixed in #9007. |
Background
Motivation
In minifier
a(b ? +0 : -0)
is currently minified toa((b, 0));
, but shouldn't, due to:The text was updated successfully, but these errors were encountered: