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.
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
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.
This moves much of the functionality that used to be defined in
the derived `FromArgs::from_args` and into a shared function. This helps
to shave off some shared code.
The option `--` acts as an "option delimiter" -- all arguments
which come after that point are treated as position arguments,
even if they begin with `-`. This functionality was added in #60.
However, there was a slight issue. Because the `--help` flag is
parsed separately from the rest of the arguments, `--help` would
trigger the early-exit help message, even after `--`.
Following the Fuchsia CLI Tool Rubric
(https://fuchsia.dev/fuchsia-src/concepts/api/cli#option_delimiter),
this adds support for "--", which denotes the end of the options list.
All arguments that come after this point will be treated as positional,
even if they begin with "-".
Closes#58. Closes#59.
