Fix no_std build failure

[CryZe]

{f32|f64}::round() does not exist with just core, so libm's implementation is used instead when the std feature is not activated.

[CryZe]

I have no idea what's going on here tbh. cargo test --no-default-features with

#[cfg(not(test))]
use libm::{F32Ext, F64Ext};

spits out

warning: unused import: `F32Ext`
   --> palette/src/lib.rs:172:12
    |
172 | use libm::{F32Ext, F64Ext};
    |            ^^^^^^
    |
    = note: #[warn(unused_imports)] on by default

warning: unused import: `F64Ext`
   --> palette/src/lib.rs:172:20
    |
172 | use libm::{F32Ext, F64Ext};
    |                    ^^^^^^

[Ogeon]

Hmm... strange, but good catch! I wonder how it passed the tests in the first place. Did you compile with any specific feature set, or just all of them disabled?

Either way, the float trait business is a bit weird and convoluted, but take a look in the float.rs file. That's where we have all the mappings to libm, and that's where you can add this code too.

[CryZe]

Because the tests are always built with std. You can't run tests with no_std. The only way to appropriately check for no_std compatibility is to cargo build --target thumbv6m-none-eabi --no-default-features. (Although what is tested I guess is whether the libm crate works as advertised)

[Ogeon]

Oh, right! I forgot about that. 🤦‍♂️ Classic and not so strange after all. Do you think you can add a compile test in the test_features.sh file? Both to check this and future mistakes.

[CryZe]

Unfortunately this gets even harder because the lock file also contains the dev dependencies which make the command I posted also not work due to the cargo bug where features of dev dependencies leak into your normal dependencies. So we would need a separate crate specifically to test no_std compatibility that depends on palette. The state of no_std in Rust is honestly still pretty sad tbh.

[Ogeon]

That's annoying. One would think the dev dependencies would be isolated. In that case it may be better if it's added in a separate issue and PR, to keep the scope of this one focused. I have obviously not investigated the general no_std situation enough, but I suppose it would be good to try to test for it not being leaked, too. So it's doesn't sound like a quick addition.

[Ogeon]

Great! There's just that one import that doesn't need to be in lib.rs. 🙂

[CryZe]

Too late, that's already gone :P

[Ogeon]

You are too fast for me 😁

I guess that's why it seemed to glitch a bit when I started the review.

[Ogeon]

The builds look good so far, so I'll approve this. I'll also create an issue for setting up no_std tests.

[Ogeon]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push