-
Notifications
You must be signed in to change notification settings - Fork 3
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
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: