Feat: borsh, serde, and address no_std #355
Conversation
There was a problem hiding this comment.
Thanks for your contribution! These are great changes.
I went through and made the suggested changes myself, especially for removing the alloc feature from the serde dep by default, since that was a bit painful to test. It should get CI to pass too: https://github.com/joncinque/solana-sdk/tree/borsh-no-std
Feel free to apply them if you want!
Co-authored-by: Jon C <[email protected]>
Co-authored-by: Jon C <[email protected]>
There was a problem hiding this comment.
Just one last nit, then just need to run ./cargo nightly fmt --all for the rustfmt issue.
Separately, I'm wondering how we can test this. The upstream BPF target is no-std, but also doesn't allow for alloc. I looked through different possible targets that are no-std but allow alloc, and found this list: https://github.com/search?q=repo%3Arust-lang%2Frust+path%3A%2F%5Esrc%5C%2Fdoc%5C%2Frustc%5C%2F%2F+%22core+and+alloc%22&type=code
Of those targets, maybe we can add a check for building wasm32v1-none with no-default-features and alloc, borsh, and serde enabled. The other targets didn't seem as relevant, but we could always use another.
I took a stab at it with https://github.com/joncinque/solana-sdk/tree/alloc-ci -- let me know how it looks!
| serde = ["dep:serde", "dep:serde_derive"] | ||
| sha2 = ["dep:solana-sha256-hasher", "error"] | ||
| std = ["decode"] | ||
| std = ["decode", "borsh?/std", "serde?/std", "alloc"] |
There was a problem hiding this comment.
nit: Can you add a comment above this saying to remove the enabling of alloc during the next breaking release?
There was a problem hiding this comment.
I'm not sure we'd want this. I think std should probably enable alloc as well
There was a problem hiding this comment.
We're going to break up a few of these features, but it's true that it might be odd to need to enable both separately. What do you think @febo ?
There was a problem hiding this comment.
Agree, I think we should enable alloc when std is enabled – feels like it would be the expected behaviour since the std includes alloc.
Are you certain this is the case? If you add alloc with cargo +nightly build -Zbuild-std=alloc,core --target=bpfel-unknown-none --no-default-features --features "decode, error, sanitize, syscalls, borsh, serde, bytemuck" |
That's much smarter, let's do that. Can you add another line in |
Done @joncinque! |
There was a problem hiding this comment.
looked at tx-metadata crates. the functional change seems fine.
curious about the practice of Cargo formatting in this repo - there are a few lines that seem to be changed without reason. Is this not formatted as part of CI somehow? seems like different formatter settings could cause a lot of annoying churn if not.
We run |
This was annoying me as well. I'm pretty sure I'm just using the defaults in vscode, so not super sure why it was messing things up |
Disables default features for
serdeandborsh, enabing no_std support. That on its own shouldn't be a breaking change since neither dependency is re-exported. Also updated the address crate to support no_std with alloc/borsh/serde enabled.I enabled no_std for the
atomic-u64crate, but atomics aren't actually supported on thebpfel-unknown-nonetarget (unless I'm configuring something wrong, which very well could be the case). Can definitely remove that change, but still probably beneficial for other no_std targets that do support atomics.To check that this all works I ran the following in the address crate:
cargo +nightly build -Zbuild-std=alloc,core --target=bpfel-unknown-none --no-default-features --features "decode, error, sanitize, syscalls, borsh, serde, bytemuck"Closes #354