no_std support #57
Comments
|
Hi! Yes, for sure. At the moment this is difficult because I'm using the dynamic CPU feature detection in std -- eg https://doc.rust-lang.org/std/arch/macro.is_aarch64_feature_detected.html -- while avoiding that is easy on x86, I think the story on ARM is less clear. |
|
Adding a feature to disable it and assume the target supports everything and/or receive the features from the caller might be sufficient? Probably later in the development though :) |
Yes. Even simpler would be to require anyone using that feature specifies the features statically at compile time (using |
|
Having a way to override probably would make their life simpler. In the future a beefy quasi-embedded risc-v that may or may not have RVV enabled might enjoy having a mean to pass the information since it usually comes from the device tree or the bootloader. (I opened the issue because rustyguard has a WIP patchset that tries to use graviola directly and I got curious) |
This makes it possible to use the `?` operator with `graviola::Error` in application code that uses e.g. `anyhow`. The required implementations of `core::fmt::Display` are simply based on the docs for each variant, converted to the standard lowercase, non-punctuated style. This currently used `std::error::Error` instead of `core::error::Error` because the latter would mean a `rust-version` bump up to 1.81. Depending on what happens with ctz#57, this could perhaps use some feature flag(s) to conditionally use `std` or `core`. Or hide the entire trait impl behind a feature flag.
This makes it possible to use the `?` operator with `graviola::Error` in application code that uses e.g. `anyhow`. The required implementations of `core::fmt::Display` are simply based on the docs for each variant, converted to the standard lowercase, non-punctuated style. This currently used `std::error::Error` instead of `core::error::Error` because the latter would mean a `rust-version` bump up to 1.81. Depending on what happens with ctz#57, this could perhaps use some feature flag(s) to conditionally use `std` or `core`. Or hide the entire trait impl behind a feature flag.
This makes it possible to use the `?` operator with `graviola::Error` in application code that uses e.g. `anyhow`. The required implementations of `core::fmt::Display` are simply based on the docs for each variant, converted to the standard lowercase, non-punctuated style. This currently used `std::error::Error` instead of `core::error::Error` because the latter would mean a `rust-version` bump up to 1.81. Depending on what happens with #57, this could perhaps use some feature flag(s) to conditionally use `std` or `core`. Or hide the entire trait impl behind a feature flag.
Would be in-scope making graviola no_std+alloc?
The text was updated successfully, but these errors were encountered: