| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
With the recent patch set moving us to using structopt over argparse we
introduced all new structs and enums representing subcommands and the
like as public. That is unnecessary, as they are not accessed from the
outside.
This change adjusts the visibility accordingly.
|
| |
|
|
|
|
|
|
| |
This patch introduces two changes to the Command! macro:
- We allow variants without fields so that we no longer have to define
empty *Args structs just for the Command! macro.
- We allow doc comments so that we can document commands without a
separate *Args struct.
|
| |
|
|
|
|
|
|
|
| |
To make it easier to list all possible values for a command-line option
mapped to an enum, we add the all_str function to the Enum! macro that
returns an array of the string representations of all variants.
We also use this new function to simplify the generation of the error
message in the FromStr implementation in Enum!.
|
| |
|
|
|
|
|
| |
As we no longer have to implement the Display and AsRef traits for the
enums generated with the Command! macro, we don’t have to set a string
representation either. So we can drop this argument from the Command!
macro.
|
| |
|
|
|
|
| |
In the previous patches, we replaced argparse with structopt and removed
the argparse dependency. This patch removes the code that was only
needed for argparse.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the argument handling code to use structopt instead
of argparse using the data structures we introduced in the last patch.
As part of that transition we replace the old Error::ArgparseError
variant with ClapError that stores a structopt::clap::Error.
Because of that replacement, the format of the help messages changed,
breaking some of the tests. Hence, this change adapts them accordingly.
Also clap currently prints the version output to stdout, so we ignore
the version_option test case for now.
|
| |
|
|
|
|
| |
As a preparation for the structopt transition, we derive StructOpt for
the enums generated by Command! so that they can be used as a
subcommand.
|
| |
|
|
|
|
|
| |
For the transition to structopt, we have to be able to easily construct
enum variants once we have added fields to them. Therefore we implement
the Default trait in the generated macros by choosing the first variant
as the default.
|
| |
|
|
|
|
| |
To be able to use the enums generated by Command! with structopt, we
have to be able to add fields to them. This patch adds a new variant to
the Command! macro that supports fields.
|
| |
|
|
|
| |
For easier refactoring, we remove the internal enum_int! macro and
instead copy its code to the Enum! and Command! macros.
|
| |
|
|
|
|
|
|
|
| |
In one of the next patches, we will add fields to some Command variants
to be able to use them with structopt. Then we will no longer be able
to instantiate them directly, so we replace these instances for the
transition.
This patch also removes the cmd_help! macro that is no longer needed.
|
| |
|
|
|
| |
structopt requires that FromStr::Err implements std::fmt::Display.
Therefore we now return a String that contains a list of allowed values.
|
| |
|
|
|
|
| |
For an easier transition to structopt, this patch splits the two cases
of the Enum! macro into two separate macros (that internally both call
the new enum_int! macro).
|
| |
|
|
|
|
|
|
|
|
| |
The input to the Enum macro is supposed to resemble the definition of an
enum in Rust code. When manually defining an enum (or a struct for that
matter), we typically terminate all branches with a comma, and don't
just omit that on the last line.
To mirror this behavior, this change adjusts the Enum macro to accept
(and in fact, require) a comma-terminated last line as well, as opposed
to not accepting it as had been the case so far.
|
| |
|
|
|
|
|
|
|
| |
Macros typically should reference types by their full path and not
assume that they are in scope wherever the macro is expanded. We did
missed one spot where AsRef was not fully qualified in the Enum macro.
While that is not much of an issue here (and there may be more
occurrences, e.g., in the auto derives) lets fix that up for the sake of
consistency.
|
| |
|
|
|
|
|
|
|
| |
The previous change to properly format the help text for optional
arguments left one thing out: parameters that are based on an Option as
opposed to an enum. The problem with those is that we cannot simply ask
the value (i.e., the Option) for all the variants of the inner type.
Instead, we have to reference the actual type of the inner enum in order
to retrieve all its possible variants.
|
| |
|
|
|
|
|
|
|
| |
With the ability to fully generate the command enums we use for working
with the argparse crate, we can now take things one step further and
populate the contents of the help string we print for the user that
lists the available commands.
Doing so we also fix a bug where we forgot to mention the "storage
status" command in the help text.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not too long ago we added a macro to auto generate the command enums and
the required trait implementations from a concise declarative
representation. This change extends this mechanism to the execute method
implementation that some of those enums provide.
When a tuple is specified as the "destination", e.g., here:
> Enum! {ConfigCommand, [
> Get => ("get", config_get),
> Set => ("set", config_set)
> ]}
the second component of this tuple will be interpreted as the function
to invoke when this variant used in the newly generated execute method.
|
|
|
The argparse module we use for parsing events expects an enum in order
to convey what subcommand has been supplied as an argument. Such an enum
also needs to implement str::FromStr and, preferably, fmt::Display.
Manually writing down those definitions is error-prone, tedious, and
adds no value -- only lines of code.
As it turns out the proper definitions can be generated with relative
easy with a declarative macro, making the code much more concise. Hence,
with this change we use a newly introduced macro for generating those
enums.
|
