Commit graph

25 commits

Author SHA1 Message Date
Ed Page
ddac492302 fix: Rename IntoApp to CommandFactory
This is part of the `App` rename.

Previously, I was concerned about not being able to deprecate

For backwards compatibility, we still expose the `IntoApp` name.
2022-02-15 08:24:00 -06:00
Ed Page
c3fec1fa75 fix: Update derive->Command function name
No good solution for transitioning the trate name, unfortnately, since
we can't mark `use`s as deprecated (we can, it just does nothing).

I got rid of the `into` prefix because that implies a `self` parameter
that doesn't exist.
2022-02-14 16:04:10 -06:00
Ed Page
e8010e79a9 refactor: Update app variables to cmd 2022-02-14 15:55:56 -06:00
Ed Page
c4144d7d6c docs: Update App references to Command 2022-02-14 15:33:49 -06:00
Janik Rabe
7b1ea308a0 fix(derive): Use fully qualified types
This fixes `#[derive(Parser)]` when a custom `Result` type is in scope.
2021-12-08 21:07:49 +00:00
Ed Page
57e5fc2b07 fix: Rename to Arg::ignore_case like ArgSettings
Fixes #32
2021-11-29 10:34:42 -06:00
Ed Page
53e10b41e3 fix(derive)!: Error, don't panic!
The derive is generating `Error::raw` (from scratch or by converting
existing erors) and then the inherent `Parser` methods format them.

Fixes #2255
2021-10-26 14:26:50 -05:00
Ed Page
9f12bfec47 fix!: Rename ArgValue to PossibleValue
In considering potential work for #2683, I realized we might need a type to carry data for
each of the `multiple_values`.  `ArgValue` works both for that and for
possible values, so we need to come up with a better name for one or
both.  Changing `ArgValue`s name now would be ideal since its new in
clap3 and by renaming it, we can reduce churn for users.

While thinking about this, I realized I regularly get these mixed
up, so renaming `ArgValue` to `PossibleValue` I think will help clear
things up, regardless of #2683.
2021-10-19 10:10:37 -05:00
Ed Page
d840d5650e fix(derive)!: Rename Clap to Parser.
Before #2005, `Clap` was a special trait that derived all clap traits it
detected were relevant (including an enum getting both `ArgEnum`,
`Clap`, and `Subcommand`).  Now, we have elevated `Clap`, `Args`,
`Subcommand`, and `ArgEnum` to be user facing but the name `Clap` isn't
very descriptive.

This also helps further clarify the relationships so a crate providing
an item to be `#[clap(flatten)]` or `#[clap(subcommand)]` is more likely
to choose the needed trait to derive.

Also, my proposed fix fo #2785 includes making `App` attributes almost
exclusively for `Clap`.  Clarifying the names/roles will help
communicate this.

For prior discussion, see #2583
2021-10-09 20:12:03 -05:00
ModProg
08e8c53862 refactor(ArgEnum): replace unwrap with except, arg_value -> to_arg_value 2021-10-01 16:14:10 +02:00
ModProg
15fcf814c2 fix dummies 2021-09-29 19:05:16 +02:00
ModProg
ac1a9d6d13 address epage's remarks 2021-09-27 22:06:17 +02:00
ModProg
76f7211d8b small changes 2021-09-27 01:29:10 +02:00
ModProg
b589a6ce06 feat(derive:arg_enum): use ArgValue in ArgEnum trait 2021-09-26 16:32:46 +02:00
Ed Page
52d3942ba6 fix(derive): Reduce compiler error noise
It looks like CI hasn't been running on this and we've introduced some
problems.  It looks like we had an off-by-one error in the check for
MSRV for deciding to run ui tests.
2021-07-30 10:19:21 +01:00
Ed Page
7f08773a5a fix(derive)!: Compile-error on nested subcommands
Before, partial command lines would panic at runtime.  Now it'll be a
compile error

For example:
```
pub enum Opt {
  Daemon(DaemonCommand),
}

pub enum DaemonCommand {
  Start,
  Stop,
}
```

Gives:
```
error[E0277]: the trait bound `DaemonCommand: clap::Args` is not satisfied
   --> clap_derive/tests/subcommands.rs:297:16
    |
297 |         Daemon(DaemonCommand),
    |                ^^^^^^^^^^^^^ the trait `clap::Args` is not implemented for `DaemonCommand`
    |
    = note: required by `augment_args`
```

To nest this, you currently need `enum -> struct -> enum`.  A later
change will make it so you can use the `subcommand` attribute within
enums to cover this case.

This is a part of #2005
2021-07-15 11:45:13 -05:00
Ed Page
6cc76e7237 fix(derive): Clap should not derive ArgEnum
While having convinience derives can be helpful, deriving traits that
are not used in similar situations (`Clap` and `ArgEnum`) can make
things harder
- From a user, derives are opaque and create uncertainty on how to use
  the API if not kept crystal clear (deriving a name gives you the trait
  by that name)
- This makes documentation harder to write and read
- You can use types in unintended places, which is made worse for crate
  APIs because changing this breaks compatibility.

Fixes #2584
2021-07-14 10:50:26 -05:00
David Yamnitsky
09014258cb Use clap instead of ::clap in clap_derive 2020-12-15 15:20:21 -05:00
Luca Barbato
3e51839383 Rename the update trait methods 2020-11-14 10:58:30 +01:00
Luca Barbato
5d342a7438 Update to the new from_subcommand logic 2020-11-14 10:17:13 +01:00
Luca Barbato
a9276576d7 wip: Add a variant for augment* for updates 2020-11-14 10:17:13 +01:00
Luca Barbato
d1fc83a8fa wip: Add update_from_arg_matches to FromArgMatches 2020-11-14 10:17:13 +01:00
CreepySkeleton
f0044d205d Remove a redundant lifetime 2020-08-05 22:33:51 +03:00
CreepySkeleton
e6cc49ecde Adjust derive 2020-08-05 17:07:13 +03:00
CreepySkeleton
3b418fe1a1 Cleaning 2020-04-30 15:11:39 +03:00
Renamed from clap_derive/src/derives/dummies.rs (Browse further)