-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Fix issue #50811 (NaN > NaN
was true).
#50812
Fix issue #50811 (NaN > NaN
was true).
#50812
Conversation
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
r? @oli-obk Do you think we need to crater according to #50811 (comment)? |
038a100
to
cf3c554
Compare
This comment has been minimized.
This comment has been minimized.
cf3c554
to
3a2bd0b
Compare
Well... the clean way would be a future compat lint. And we definitely need some team to sign off on it. That said: anyone depending on floating point corner cases for const eval things is somewhat asking for getting their code broken. We could restore the original behaviour by making const eval decide on a way to do these edge cases depending on whether it is called in a true const environment or a promoted env, that would be horrible, but doable. Though I personally would like to see this PR merged as it is. |
cc @rust-lang/lang @rust-lang/compiler -- This PR is a candidate for stable backporting (1.26.1) as it fixes a bug in const eval; if you object, please note that here. |
behavior when NaN is involved.
3a2bd0b
to
50bc72d
Compare
Discussed in the @rust-lang/compiler meeting. General consensus was that |
Ping from triage @oli-obk! How should this PR move forward? |
@bors r+ |
📌 Commit 50bc72d has been approved by |
@bors p=1 |
…li-obk Fix issue #50811 (`NaN > NaN` was true). Fix #50811 Make sure the float comparison output is consistent with the expected behavior when NaN is involved. ---- Note: This PR is a **BREAKING CHANGE**. If you have used `>` or `>=` to compare floats, and make the result as the length of a fixed array type, like: ```rust use std::f64::NAN; let x: [u8; (NAN > NAN) as usize] = [1]; ``` then the code will no longer compile. Previously, all float comparison involving NaN will just return "Greater", i.e. `NAN > NAN` would wrongly return `true` during const evaluation. If you need to retain the old behavior (why), you may replace `a > b` with `a != a || b != b || a > b`.
☀️ Test successful - status-appveyor, status-travis |
[beta] Process backports Merged and approved: * #50812: Fix issue #50811 (`NaN > NaN` was true). * #50827: Update LLVM to `56c931901cfb85cd6f7ed44c7d7520a8de1edf97` * #50879: Fix naming conventions for new lints * #51011: rustdoc: hide macro export statements from docs * #51051: prohibit turbofish in `impl Trait` methods * #51052: restore emplacement syntax (obsolete) * #51146: typeck: Do not pass the field check on field error * #51235: remove notion of Implicit derefs from mem-cat r? @ghost
[beta] Process backports Merged and approved: * #50812: Fix issue #50811 (`NaN > NaN` was true). * #50879: Fix naming conventions for new lints * #51011: rustdoc: hide macro export statements from docs * #51051: prohibit turbofish in impl Trait methods * #51052: restore emplacement syntax (obsolete) * #51146: typeck: Do not pass the field check on field error * #51235: remove notion of Implicit derefs from mem-cat r? @ghost
Fix #50811
Make sure the float comparison output is consistent with the expected behavior when NaN is involved.
Note: This PR is a BREAKING CHANGE. If you have used
>
or>=
to compare floats, and make the result as the length of a fixed array type, like:then the code will no longer compile. Previously, all float comparison involving NaN will just return "Greater", i.e.
NAN > NAN
would wrongly returntrue
during const evaluation. If you need to retain the old behavior (why), you may replacea > b
witha != a || b != b || a > b
.