(wip) no_std support #52
Conversation
Using an unmerged PR for bytes, and liballoc as the source for Box, String, Vec, and BTreeMap, the runtime bits of Prost can work with no_std
| @@ -1,12 +1,15 @@ | |||
| use std::fmt::Debug; | |||
| use std::usize; | |||
| use core::fmt::Debug; | |||
There was a problem hiding this comment.
Aren't these APIs unstable? Should probably be behind the feature gate.
There was a problem hiding this comment.
No concern with gating core, though I was under the impression that core is considered stable and alloc is unstable/experimental. I can try to get confirmation from the core team on that front.
I should be able to look at the codegen piece this week/have a review pass ready later this week.
Thanks!
There was a problem hiding this comment.
Hi @danburkert -- when looking into this further, I realized that the current proposal for no_std with the bytes crate drops/removes into_bytes() (b/c of io::Cursor). Since into_bytes() is rather critical in prost for encoding and decoding, I think it makes sense to sort out the bytes crate before going further with no_std in prost. WDYT?
|
|
Revive no_std WIP