search

Lucretiel / nom-supreme

A collection of utilities for a superior nom experience
Mozilla Public License 2.0
148 stars 10 forks source link

Make this crate no_std? #11

Open matthiasbeyer opened 1 year ago

matthiasbeyer commented 1 year ago

Hi!

Is there any chance we could get this crate for no_std usecases? From what I see, only joinery and brownstone do not have a std feature! memchr, nom and indent_write have one that could be turned off!

I am not sure whether the functionality introduced by either joinery or brownstone can simply be excluded for the no_std case (did not look that closely yet), but if you're interested, I'd have a closer look and am willing to come up with a PR if I can manage! :wink:

Related: https://github.com/TheNeikos/cloudmqtt/pull/24

matthiasbeyer commented 1 year ago

Ah, now I see that both joinery and brownstone are actually no_std.

Lucretiel commented 1 year ago

This is something I've been wanting to do, yeah. I've been playing around with a no-std split for nom-supreme every so often, especially now that ErrorTree has been made more generic and no longer depends on Box. In general I've been trying to break nom-supreme apart into several crates, but the whole thing is so tightly integrated that it's proving more challenging than expected (mostly because of how ErrorTree implements traits from the rest of the crate).

I don't have an exact vision of what would be entailed but I'm definitely open to a PR now that we have GenericErrorTree. I'd be looking for an std and alloc feature that toggles relevant crate items and dependency features.

Lucretiel commented 1 year ago

I suspect that indent_write can unconditionally have std disabled; the only thing that it adds is the io::Write trait, which I don't think nom-supreme depends on.

Lucretiel commented 1 year ago

I've got this mostly implemented but I'm now running into the OTHER problem I ran into last time which is that testing this library in no-std mode is a huge pain (because we want to be able to parse Vec and use ErrorTree in tests and so on.

matthiasbeyer commented 1 year ago

Maybe I am missing something, but why would you want to test the crate in no_std if it was already tested without no_std?

Lucretiel commented 1 year ago

Mostly I want to be able to run cargo test --no-default-features. I suppose if the normal tests are good enough that cargo build --no-default-features is sufficient, though.