Add no_std compatibility

[elast0ny]

Feature Request Summary

Would it be possible to split clap argument parsing logic into a no_std "clap_core" crate or allow crates to toggle a no_std style feature.

This would probably strip most of the clap features such as print_help(), exiting on error, loading from yaml, etc... but the core argument parsing logic should still work.

no_std clap could expose a .get_matches_from() like function which could return a ClapResult<ArgMatches<'a>> leaving the error handling up to the caller. Optionally, no_std clap could also expose ways to get pre-formated help/long_help buffers for crates who wish to display the information.

Current Behavior

Clap is incompatible with no_std

[CreepySkeleton]

Marking for 3.0 milestone because it would be breaking change

[Dylan-DPC-zz]

This needs some work and depend on the demand (cli in environments where you want no_std is niche iirc). We can push this for a future release

[pksunkara]

I agree, this is not breaking if we just add a new feature to cargo. We can push this.

[BurntSushi]

You'll want to add a std feature that is enabled by default and produces a compilation error when it is disabled. Otherwise it's quite likely that you'll break extant uses of default-features = false.

[pksunkara]

@BurntSushi Thanks for the input. I haven't worked with no_std before. Is this the standard way of doing things? Is there any issue with adding no_std feature instead?

[BurntSushi]

Yes it is standard. Features should be additive, since enabling them in a dependency enables it for all instances of that crate in a dependency tree.

The main point here is to make sure you add the feature in clap 3, so that you can add it later in a backwards compatible fashion.

(I would personally be surprised if making clap compatible with no_std was easy without significant changes to the public API. Perhaps an alloc-only version would be simpler. But I confess that I have not thought deeply about it.)

[Dylan-DPC-zz]

Don't worry. I'll handle the no_std part. Well generally the default crate should be in no_std and then std is added as a new feature. The problem with that is it is difficult to do it in a non-breaking way. Also I don't want to keep the release waiting for it, so likely it will happen in a minor release in the future in a non-breaking (or a short term solution ) or properly in 4.0

[BurntSushi]

@Dylan-DPC Hmmm, I'm not sure if I conveyed my thoughts well enough. What I'm saying here is that with the clap 3 initial release, you can add a std feature that is enabled by default. When it is disabled, you can use compile_error!(...) to cause it to always fail. That way, once you do decide to add the feature, you can make whatever changes you want since the lack of a std feature previously never compiled anyway.

This is exactly the approach that the regex crate takes, with the hope of providing an alloc-only mode in the future.

[Dylan-DPC-zz]

I've added a dummy no-op feature in 6aaeb27

[barafael]

It would also be very useful to be able to derive ArgEnum for enums from no_std crates.

E.g.:

    #[clap(default_value = "None", possible_values = &["None", "Odd", "Even"])]
    parity: Parity,

where Parity is an enum defined in some no_std driver for which one is currently writing a CLI.

[felipebalbi]

Support for no_std would be super useful in environments such as UEFI where one can rely on uefi-rs to write applications for it.

[ChandlerPrue]

This ticket looks pretty stale. I just tested the no_std in 4.5.11 and see its still dependent on std. As someone trying to compile for UEFI i'd support this feature, but would also appreciate the clarity of closing this issue if its not being considered anymore

[epage]

would also appreciate the clarity of closing this issue if its not being considered anymore

Just because something is stale doesn't mean it won't be considered any more. There are lots of features of interest and limited capacity to move them forward.