Summary:
This makes it possible to use explicitly named arguments. It can simplify the
code a bit by moving the error handling (incorrect number of arguments) to the
derived code.
Reviewed By: xavierd
Differential Revision: D16905460
fbshipit-source-id: 93dc58d684bb52cd2f9bddc25108ef0c500f81db
Summary:
If there is no `#[args]` field set, the command does not need arguments. In
that case, just error out directly. This can simplify command implementations.
Reviewed By: xavierd
Differential Revision: D16905461
fbshipit-source-id: f4a2d03cf032f34d1b5794010774ff80eb88e1cd
Summary: This make it possible for the flags parsing to return an error.
Reviewed By: xavierd
Differential Revision: D16905462
fbshipit-source-id: 06a70ee7c72132ebb2df453a740b58e6b46dfba2
Summary:
Most commands do not care about the "command name" (aka. arg0). Only commands
sharing a similar implementation (ex. hg up/down/bottom/top) would need it.
Make it optional and make `args` not containing the command name.
Reviewed By: xavierd
Differential Revision: D16905459
fbshipit-source-id: 0a786731ebce2580e116fd50aad75062b03a1fa3
Summary: This makes the code easier to read as we add more fields to the macro state.
Reviewed By: xavierd
Differential Revision: D16905458
fbshipit-source-id: a3bc4dc1accf21cf491921469482f86aec16321b
Summary:
This is more conistent with Mercurial style. And make them usable directly in
Rust code.
Reviewed By: sfilipco
Differential Revision: D16796397
fbshipit-source-id: 9016ea2b09fdf96b2b54138f5c8405caf96390f7
Summary:
This makes the "content" of the error stable. It is used in a later diff where
AmbiguousCommand gets handled by Rust directly instead of falling back to
Python dispatch.py.
Reviewed By: sfilipco
Differential Revision: D16796404
fbshipit-source-id: c439db14ec83c76c4762d3c627bfce1ea44bccf4
Summary:
This makes it possible to use one structure instead of a structure + another
`args` list.
The current version only supports a `Vec<String>` field and there is no verification
about how many arguments that `Vec<String>` can have. In the future we can add:
- Verification about arguments. Potentially change `From<ParseOutput>` to `TryFrom<ParseOutput>`.
- Individual named arguments as individual fields.
Reviewed By: sfilipco
Differential Revision: D16733272
fbshipit-source-id: 2bb407fff6cd1790cf33e8ce5527bb5e44255215
Summary: This can make code shorter.
Reviewed By: sfilipco
Differential Revision: D16733264
fbshipit-source-id: 27c0299c6e59bc30cfa14aa9ce122e2a542fd9c1
Summary:
Alias starting with `!` are considered shell commands. The entire command
string should be passed roughly as-is to the shell.
The current alias handling uses shlex::split to split the alias into arguments,
then replaces things like `$1` in arguments. The problem is, escaping
shlex::split a complex shell alias, then unesape (shlex::quote) it is not
loseless.
To maintain compatibility for existing complex shell alias configuration,
add a new code path that imitates the Python code behavior.
Reviewed By: sfilipco
Differential Revision: D16814144
fbshipit-source-id: 0e5e95f99bf8b8b16bd8d0cbcadd6760f7f77ebb
Summary: `--no-foo` should only work if `foo` is a boolean flag.
Reviewed By: farnz
Differential Revision: D16715454
fbshipit-source-id: 9a8183586aa50fb55f30e19276bd60ebcc23a5fb
Summary: The helper function is no longer necessary.
Reviewed By: sfilipco
Differential Revision: D16715455
fbshipit-source-id: 3bf528d3c9f18418724793edebf298425a3bba87
Summary:
Previously, `get` returns an `Option<T>`. Almost all callers use `unwrap`
immediately, since they know what flag names are available. Let's just
move the `unwrap` inside the function. `get` in the Rust (and Python)
eco-system is considered nullable and panic-free. Rename it to `pick`
to make the difference more obvious.
I considered using the `Index` trait, but it has to return a reference,
which does not fit into this use-case.
Reviewed By: sfilipco
Differential Revision: D16715453
fbshipit-source-id: f754d208c4a1b0adeddaee82c7db82c790d6436c
Summary:
The default value of a flag is already provided with the flag. Therefore
`get_or_default` requiring another `default` does not make much sense.
Remove it.
Reviewed By: farnz
Differential Revision: D16713531
fbshipit-source-id: 95a55289077b7308083b6685f013d1058419a675
Summary:
This simplifies a lot of code. For example:
- let config_path: Vec<String> = result.get("config").unwrap().clone().try_into().unwrap();
+ let config_path: Vec<String> = result.get("config").unwrap();
Also, the use of `TryInto` does not make sense - the code only implements
`Into`, and `TryInto` will panic. Therefore remove `TryInto`.
Reviewed By: farnz
Differential Revision: D16713534
fbshipit-source-id: 29dc71881dd844fa87e086543fb0a3bb5d8837a1
Summary:
Replace `_` in field names to `-` as long flag name. That is consistent with
the current hg behavior.
Reviewed By: sfilipco, farnz
Differential Revision: D16713530
fbshipit-source-id: ce36caebc6b3131cb418d86ca0fdc507d2d8f17f
Summary:
Change the macro to have state so we can parse fields one by one with different
syntax.
Reviewed By: sfilipco
Differential Revision: D16713536
fbshipit-source-id: 7f8cb63cfa0ea000c2c2a431454c2d88d49b9187
Summary:
This macro provides `Vec<Flag>` and implements `From<ParseOutput>` for a
struct intended to be used as command options.
The core macro is just 21 lines. Both structopt-derive and gumdrop_derive have
1000+ lines.
Of course, it lacks of features. Some of those features are:
- No way to provide a "short flag".
- Default values have to be explicitly written.
- No way to compose structs (ex. reuse DiffOpts)
- Should "args" be part of the structure?
- Should "command help" be part of the structure?
Reviewed By: sfilipco
Differential Revision: D16713535
fbshipit-source-id: e8137e5f110ebb280fc40f84dace7b1d3a346c82
Summary:
The vendored shlex crate was used to unblock progress. Now that `shlex`
is available in tp2 crate, let's drop the vendored shlex.
Reviewed By: farnz
Differential Revision: D16706184
fbshipit-source-id: f110ee91d8c9cc61b94fbafbf269f260bd73fd70
Summary:
`extension-module-2-7` should only be used for "extension modules". They change
link behavior and can cause issues. In our cases, only "python27-sys" is actually
used.
Reviewed By: farnz
Differential Revision: D16706183
fbshipit-source-id: cd2474556f92bb3697a2d209a790baf063195c50
Summary:
Encourage the use of `ParseOptions`. Most users will use
`ParseOptions::parse_args` without using a `Parser`.
Reviewed By: farnz
Differential Revision: D16703010
fbshipit-source-id: 33cc839228dc2d7fe9618c9d83720af2bdc0e1f7
Summary:
This makes `ParseOptions` own all information to do a parse so parsing can be
done without creating a `Parser` struct:
ParseOptions::new().flags(flags).parse_args(args)
`Parser::with_parsing_options` is removed since that will overwrite `flags`.
Some `unwrap()`s in the bindings are replaced with proper error handling.
In the future it might make sense to make `Parser` or `Parser::new` private.
Reviewed By: farnz
Differential Revision: D16703009
fbshipit-source-id: 6119c29d934ae4410b31d906397a902c03e27fe2
Summary:
`Flag` and `FlagDefinition` serve similar purposes.
Keep `Flag` and drop `FlagDefinition`.
Reviewed By: farnz
Differential Revision: D16700315
fbshipit-source-id: 1b7d1afb1bde01b9781f9d1295a1494053471062
Summary: Migrate them to use `Flag::from` or `tuple::into` to build `Flag`s directly.
Reviewed By: farnz
Differential Revision: D16700692
fbshipit-source-id: e5a7ce3b937f482149c9a84e4e1ab1a8807dfe4c
Summary: Migrate them to use `Flag::from` or `tuple::into` to build `Flag`s directly.
Reviewed By: farnz
Differential Revision: D16700305
fbshipit-source-id: 4511607360e1a2ceb7accbb2cb745bf1069c2920
Summary:
The "global flags" concept is more coupled with the "hg dispatch" logic.
The "cliparser" crate can stay pure from application-specific flags.
As we're here, update the global flags definition to use `Into::into`,
and return `Vec<Flag>` directly, instead of `Vec<FlagDefinition>`.
That removes one usecase of `FlagDefinition`.
Reviewed By: farnz
Differential Revision: D16700307
fbshipit-source-id: 2688cb06272a249454d92d7d7d5a0b1100805dbd
Summary:
The goal is to simplify the API, keep only the `Flag` structure, and remove
`FlagDefinition`.
Type parameters is used to make the API more flexibile to use.
Reviewed By: farnz
Differential Revision: D16700311
fbshipit-source-id: cab894ca21679540e789dbbfe4958facab0d7bbd
Summary: The field not only decides the type, but also provides the default.
Reviewed By: farnz
Differential Revision: D16700308
fbshipit-source-id: 73aec2c227c7ce6f5b19aa5ae093f37f0b265cd3
Summary:
This helps removing references. The internal structure of `Parser` is changed a
bit to avoid storing `Flag` copies.
Reviewed By: farnz
Differential Revision: D16700316
fbshipit-source-id: 01d66feb8bd5cc2fa9394b3635f97e098143597d
Summary: `char` is only 4 bytes. Using the concrete type is faster than a reference.
Reviewed By: farnz
Differential Revision: D16700306
fbshipit-source-id: d7f198238005ec5a0061ed79724b795cd1e5077b
Summary:
This is a step towards:
- Getting rid of `<'a>` lifetime from `Flag` and `FlagDefinition`.
- Getting rid of `FlagDefinition` - it's too similar to `Flag` and is not
really a dedicated type (it's a type alias).
Reviewed By: farnz
Differential Revision: D16700313
fbshipit-source-id: b517d5203bcd1eff3381c7c6ae1020965bd135b0
Summary:
It does not make much sense for a flag to not have a description, and there are
no users depending on that. Therefore drop the `Option`.
Reviewed By: farnz
Differential Revision: D16700318
fbshipit-source-id: 4566cf339088ba69b64dd8a316a9f36fb1fac81b
Summary:
Leading underscores are uncommon in Rust. Since `parse_args` just calls `_parse`,
merge `_parse` into `parse_args`.
Input types of `parse_args` are changed a bit to be more flexible.
Reviewed By: farnz
Differential Revision: D16700314
fbshipit-source-id: 6e13ca7796cbb535fef79e3a723002bf7ef8d6f6
Summary: The options decides how the parser works. It is not opening anything.
Reviewed By: farnz
Differential Revision: D16700310
fbshipit-source-id: c0ab69f9d8c50664dc157ef0eb0f12ee1533e81d
Summary:
This removes the warning:
warning: cliparser/Cargo.toml: `default-features = [".."]` was found in [features]. Did you mean to use `default = [".."]`?
Reviewed By: sfilipco
Differential Revision: D16672732
fbshipit-source-id: 2c7478c54f0302113d4e065f88631c096757e829
Summary:
Fix the regression caused by D16557266 on error message. The fix is not the
most efficient, though. But it should restore the behavior.
Reviewed By: singhsrb
Differential Revision: D16557654
fbshipit-source-id: 2eb6956f99c931f94201b875c8bebb2219a794f0
Summary:
When doing command name prefix match, if there are a unique match for non-debug
commands, use it. This solves `hg d` regression.
Note: we cannot simply use `starts_with("debug")` to test debug commands. That
is because debug commands can have aliases (ex. `debug|dbsh` as the command
name definition, and `dbsh` is also a debug command that does not starts with
`debug`). Therefore it gets a bit complex.
Reviewed By: kulshrax
Differential Revision: D16557266
fbshipit-source-id: 42d814940c9217d9e554bd0fe2769a53e0ee467f
Summary: Suggested by kulshrax, `I` and `l` are harder to distinugish. Rename it to clarify.
Reviewed By: kulshrax
Differential Revision: D16556868
fbshipit-source-id: 5892f0730f5205534851c5f7c024ff98f751423d
Summary: This just makes the code slightly more confident.
Reviewed By: kulshrax
Differential Revision: D16556871
fbshipit-source-id: 5304c3e60c80242974d35a53aace84f829418bb8
Summary: This will be used to accurately replace the command line arguments.
Reviewed By: kulshrax
Differential Revision: D16556870
fbshipit-source-id: efb77a0da17c436e0123354746ba85201813992a
Summary: Expand `$1`, `$2` etc. in aliases. There are users depending on this behavior.
Reviewed By: kulshrax
Differential Revision: D16531016
fbshipit-source-id: fed735339adc82c4f52b74c4c4d62818bc047809
Summary:
This avoids calculating the full alias map, and provides more flexibility (ex.
the function can take care of `defaults` handling).
Reviewed By: kulshrax
Differential Revision: D16530514
fbshipit-source-id: 63558da5c9af36b2f8bc7689174fed71593a8186
