-
Notifications
You must be signed in to change notification settings - Fork 75
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
Add support for no_std
compilation (updated)
#177
base: main
Are you sure you want to change the base?
Conversation
This was the conclusion of #74: #74 (comment) |
What do you think of the use case mentioned above?
|
I am not sure how to replicate the warnings in the "Run |
@fitzgen counter question to the implementation constraints concern: is it really as bad as your comment makes it seem to restrict ourselves to libcore in the few circumstances where doing so would be necessary? I'm asking because |
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.
I guess I won't be the one holding things back if everyone else wants this.
@@ -14,6 +14,7 @@ | |||
//! [`Arbitrary`](./trait.Arbitrary.html) trait's documentation for details on | |||
//! automatically deriving, implementing, and/or using the trait. | |||
|
|||
#![cfg_attr(not(any(feature = "std", test)), no_std)] |
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.
To avoid dealing with different preludes that are vs aren't implicitly in scope depending on the features enabled, we should make this crate always be no_std
. And then because the std
feature implies the alloc
feature, we can layer in imports like
#[cfg(feature = "alloc")]
use alloc::boxed::Box;
and we don't have to use any complex logic like all(feature = "alloc", not(feature = "std"))
kinds of things.
My experience has also been that tools like rust-analyzer
handle this pattern for no_std
crates better as well.
Landing this would be highly appreciated. |
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.
in favor of landing once it's fixed
See discussion in #74.
This is useful to fuzz crates in their
no_std
configuration, which may utilize different code paths in such a crate.I started by rebasing #74 but made a number of changes to split it in an
std
andalloc
feature.Fixes #38.