Refactor and improve numbers #81
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead, Number now uses an internal NumValue which might contain a Ratio<isizze>, a Ratio<BigInt> or an f64. This also fixes handling of division by zero and other Infinite and NaN results.
Different kinds of NumValue should order according to value, not according to implementation.
Neither css::Value nor sass::Value, nor lots of related types, should actually impl Ord, but only PartialOrd. This means a NumValue should not impl Ord either, and we can accept the usual and sane rules for floating-point comparions (i.e. NaN.partial_cmp(NaN) == None).
kaj
added a commit
that referenced
this pull request
Nov 10, 2020
Progress: 2718 of 5840 tests passed in dart-sass compatiblilty mode. ### Breaking changes * `SourceName` and `sass::Item::Import` was changed by #62. * `Use` was added to the `sass::Item` enum by #80. * Changes to `sass::Value` and `css::Vaue` by #81. ### Improvements * PR #80: Implement `@use` for standard sass modules. All standard modules are at least partially supported, only `sass:string` is fully supported. See issue #60 for for module support status. * PR 82: Implement hwb support in `sass:color`. Also, provide `From<Rgba>` for `css::Value` and deprecate color value constructors. * Provide `From<bool>` for `css::Value` (and deprecate `Value::bool(v)`). * PR #62: Improve `ParseError`, `SourcePos`, and `SourceName` by using located spans by [nom_locate](https://lib.rs/crates/nom_locate) in the parser. A `sass::Item::Import` now handles where each file is imported from, to improve error reporting. * PR #81: Improved number handlig. Now `Value::Number` handles both machine-sized rationals, bignum rationals and floats internally and `Value::NumberBig` is removed. Also, `Value` no longer implemnts `Ord` but only `PartialOrd`, to handle f64 NaN an infinite values correctly. * Improve parsing of `@else` clauses. * Update spec to 2020-10-29. Tested with rustc 1.47.0 (18bf6b4f0 2020-10-07), 1.44.1 (c7087fe00 2020-06-17), 1.42.0 (b8cedc004 2020-03-09), 1.40.0 (73528e339 2019-12-16), 1.38.0 (625451e37 2019-09-23), 1.48.0-beta.8 (121901459 2020-11-08), and 1.49.0-nightly (25f6938da 2020-11-09),
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Ratio<isize>and aRatio<BigInt>inside theNumbertype, so their use outside ofnumber.rsis identical.Numbermay be af64. This allowssemi-correct handling of Infinity, -Infinity and NaN.consider NaN == NaN, Infinity == Infinity and -Infinity == -Infinity. This differs from sane and normal float handling in Rust, where each NaN or infinity is unique. Therefore,actually treat float value with normal PartialOrd behaviour.f64is encapsulated in a type that implementsOrdandEq(and not just their partials)css::Value,sass::Valueand lots of related types no longer implementOrd.PartialOrdis enough.sass:mathis simplified by the fact that aNumbercan now be af64.