You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 1, 2023. It is now read-only.
A Friday afternoon jaunt.
To be merged after #2855; does the remaining work to close#2277 (and closes off some things that Dependabot was trying to upgrade).
Tested by manually running the commands; we don't have good coverage for this kind of stuff. OTOH, most of these commands are for the experimental local fuzzing mode, which is not fully supported yet. I did specifically test the `onefuzz-task managed` command which is the one used in production.
## Details
- Bump `clap` to 4.1.6
- Remove `structopt` as this is subsumed by clap now
- Bump `envlogger` to 0.10 (removes problematic dependency)
- Set `default-features=false` on `proc-maps` (removes a feature which is only needed to support FreeBSD), and bump it to 0.3
The main changes migrating `clap` are:
- `value_t!` is gone; now use `matches.get_one::<T>`. If `T` is not `String` then a parser must have been registered on the `Arg` when it was created, with `arg.value_parser(value_parser!(T))`.
- `Command::with_name` and `Arg::with_name` are now called `new`.
- `Command` and `Subcommand` were unified, and `App` is removed.
- `arg.takes_value(true)` is gone; it is the default. For flags use `arg.action(ArgAction::SetTrue)` and then retrieve the flag value with `matches.get_flag`.
This code would be simplified a lot by using the `clap::Parser` on structs, but that requires reworking the code significantly as we cannot dynamically add/remove arguments the way that this is currently done.
## Also found
Found one bug while manually testing the `onefuzz-task local` commands; see comment below.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
ansi_term
crate is unmaintained, resulting in a RUSTSEC advisory that we must ignore.Look for maintained alternatives, once they're ready, as suggested in the linked
ansi_term
issue.AB#40995758
The text was updated successfully, but these errors were encountered: