-
-
Notifications
You must be signed in to change notification settings - Fork 462
fix(no_std): provide f64
polyfills for no_std
compatibility
#1840
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
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1840 +/- ##
=====================================
Coverage 93.1% 93.1%
=====================================
Files 80 80
Lines 17693 17696 +3
=====================================
+ Hits 16478 16481 +3
Misses 1215 1215 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Added these directly to core and widgets instead of adding a dependency as discussed on discord. The uncovered lines are not important, it would be hard to test the polyfills trait implementation directly as std shadows it (and we need it to test against something), so I put the implementations in standalone functions and test these instead. |
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. It's possible that a few of these methods will no longer be necessary after some future work on the circle algorithms to avoid trig functions, but that can happen at a later date. For now this works to get over the no_std line.
Since a lot of float methods are not included in
core
, I decided to make a simple polyfills crate, so we don't have to conditionally compile every place where these methods are used.This adds a dependency, that does nothing if we use
std
. We can either:std-polyfills
(orno-std
) feature flag (additional tostd
). I did something like that here: fix(no_std): final patches needed for no_std #1833.This has one drawback - we have to use either
std
orstd-polyfills
feature flag or the library won't compile.To make it easier on the user, we can add a check in lib.rs that emitts compiler error "either std or std-polyfills feature flag must be enabled" in such cases.
float-polyfills
crate lighter, not depending on libm (or gate libm behind feature flag).Let me know what you think and if you have some other ideas for this.
Related: rust-lang/rust#137578