Skip to content
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

Support no_std usage #463

Closed
Pzixel opened this issue Jul 16, 2018 · 7 comments
Closed

Support no_std usage #463

Pzixel opened this issue Jul 16, 2018 · 7 comments

Comments

@Pzixel
Copy link

Pzixel commented Jul 16, 2018

I'm working on no_std library and I encountered a problem with serde that it doesn't work when I compile for the target (see openethereum/pwasm-abi#54 ). After some investigation I found that it seems evildoer is this crate. So I tried to replace serde in dependencies with:

serde = { version = "1", default-features = false }

It almost compiled, however I've got several erros. One of them is was

error[E0407]: method `visit_string` is not a member of trait `Visitor`
  --> C:\Users\Alex\Documents\Repo\json\src\value\de.rs:76:13
   |
76 | /             fn visit_string<E>(self, value: String) -> Result<Value, E> {
77 | |                 Ok(Value::String(value))
78 | |             }
   | |_____________^ not a member of trait `Visitor`

It's because Visitor trait has cfg attribute:

#[cfg(any(feature = "std", feature = "alloc"))]
fn visit_string<E>(self, value: String) -> Result<Value, E>;

When implementation - doesn't.

It seems that the crate was never tested against no_std environments (sorry if I'm wrong).

I could try to fix all issues myself and create a PR, but I'm not sure that I'm doing the right thing or don't.

Please, see referenced issue if you want to know why I came here with this proposal.

@dtolnay
Copy link
Member

dtolnay commented Jul 16, 2018

Please use serde-json-core if you need a no-std JSON library.

@Pzixel
Copy link
Author

Pzixel commented Jul 16, 2018

Unfortunately, it doesn't work with structs so this is a no-way. I'l try it out, however, there are several considerations.

It seems pretty easy to solve these three issues to make it non-std compatible. It probably won't be a good way to run it on devices with limited CPU/memory capabilities, but there still plenty of powerful devices that require no_std target.

So either std feature should be removed from the crate (to not confuse people that it supports some kind of no_std) or adopt no_std completely. I think the latter is the better alternative.

@dtolnay
Copy link
Member

dtolnay commented Jul 16, 2018

I am closing the issue because I don't intend to bring no-std support into serde_json as discussed previously in #362.

std feature should be removed from the crate (to not confuse people that it supports some kind of no_std)

I'm afraid I don't understand what std feature this suggestion refers to. The serde crate has a std feature because its dependency on the standard library is optional. Serde data formats without a standard library dependency exist, including the mentioned serde-json-core and a couple others. The serde_json crate does not have a std feature because its dependency on the standard library is not optional.

@dtolnay dtolnay closed this as completed Jul 16, 2018
@Pzixel
Copy link
Author

Pzixel commented Jul 18, 2018

@dtolnay I have several considerations

  1. This crate doesn't work with alloc types such as String or Vec. How can I serialize something into JSON if it doesn't support strings?
  2. It look a bit abandoned, this crate doesn't even exist on crates.io (latest version is 0.0.1, when actual is 0.1.0).
  3. It look pretty straightforward to add no_std in the crate. This restriction may be relaxed later, if required.
  4. You alredy have cfgs like
#[cfg(any(feature = "std", feature = "alloc"))]

If you don't want to support no_std you don't need to cfg based on these features.

But as I said, it hasyou have to fix only 3 places via cfgd or slight rewriting to make it work in no_std scenarios.


Author explicitely says:

This is explicitly out of scope

  • Anything that involves dynamic memory allocation
    • Like the dynamic Value type

So if I have struct with String field then I have no crate to serialize it. Sounds weird.

@Pzixel
Copy link
Author

Pzixel commented Jul 18, 2018

I'm currently in the situration where I need to serialize some Vec's and Stirngs's into json. What crate should I use and how?


In a nutshell: I'm writing a library for wasm. So I need to run without standard library (no_std) and I clearly have to serialize Strings/Vecs/etc... But I currently just can't. serde_json doesn't work with no_std, and serde_json_core doesn't work with alloc::* types.

@Pzixel
Copy link
Author

Pzixel commented Jul 19, 2018

I crated a question about it, if you are insterested: https://users.rust-lang.org/t/how-to-serialize-json-in-no-std-library/18915

@dtolnay
Copy link
Member

dtolnay commented Nov 9, 2018

I would be willing to consider a PR that adds a std feature on by default, and exposes the same or a subset of the current API of serde_json by using the alloc crate in no_std mode. Let's track this in #362.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants