This changes `from_str_fn` to take expression paths, rather than simple
idents. This makes it easier to use functions from external modules,
or with static methods.
The ArgsInfo trait exposes the information about the
arguments defined using the argh attributes. This is
intended to be used for uses that benefit from inspecting
the command line arguments exposed via a structured interface
for example, help documentation generation and CLI compatibility
detection.
The ArgsInfo trait exposes the information about the
arguments defined using the argh attributes. This is
intended to be used for uses that benefit from inspecting
the command line arguments exposed via a structured interface
for example, help documentation generation and CLI compatibility
detection.
The ArgsInfo trait exposes the information about the
arguments defined using the argh attributes. This is
intended to be used for uses that benefit from inspecting
the command line arguments exposed via a structured interface
for example, help documentation generation and CLI compatibility
detection.
Two cases here:
- invalid utf8 -- this can happen in somewhat reasonable circumstances,
so returning a graceful error is warranted here
- empty `argv` -- this one is weird, I think various things across the
stack try to actually patch that up to never bubble empty argv to an
application, but it's not to hard to add extra error handling here
<https://ryiron.wordpress.com/2013/12/16/argv-silliness/>
It can be useful to use Option<bool> in a configuration struct, in
particular if that struct can be built from another source (e.g.
deserialized from a configuration file) where boolean switches can be
explicitly set to false and we want to differenciate between the flag
being negated explicitly from it not being specified.
Thus, allow the `switch` parameters to be used on Option<bool> fields.
The field will be `None` if the switch was not specified, and
`Some(true)` if it was.
This adds a new variant of positional arguments that, once they start
processing, consume all arguments after as part of the positional
argument, as if they always had '--' in front or behind them.
This removes the restriction against deriving a struct with
FromArgs that takes generic arguments, and adds a test to make sure
it works correctly. There isn't really a good reason for this
constraint as far as I can tell, and it's surprising if you
run into it.
This patch adds support for commands which the parser may not know about
until runtime. This could be useful if we'd like to discover subcommands
at runtime, e.g. we're using a plugin system and have to enumerate our
plugin repository to know what commands are available.
This patch adds support for commands which the parser may not know about
until runtime. This could be useful if we'd like to discover subcommands
at runtime, e.g. we're using a plugin system and have to enumerate our
plugin repository to know what commands are available.
This cleans up clippy lints, both in the library itself, and in the
generated code. As part of this change, it changes a few locations where
we would have panicked on values passed in by the user to instead return
an error.
However, I left one place that unwraps in the generated code. After we have
parsed all the arguments, we check that all of the required arguments. If
not, we return an error. It's unfortunately a little difficult to prove
to rust that we've handled all the arguments. I left the unwrap()s in place
in case there's a logic error we have in handling this, and annotated the
code with `#[allow(clippy::unwrap_in_result)]` to allow for this case.
Closes#114
https://github.com/rust-lang/rust/pull/85200 changed rust to emit more
unused warnings if fields in a struct are ultimately never read. This
adds a test to make sure that we don't experience these warnings.
This changes redacted positional arguments from using the field name to
using the arg name. This allows the field name to be changed without
impacting the redaction.
In addition, this fixes all the outstanding warnings.
