Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

Please see the contribution instructions for more information.

@bors r+ rollup

Yeah, consolidating this into one place may be a little difficult but likely worthwhile.

📌 Commit e4bbbac has been approved by Mark-Simulacrum

Yeah, I was a bit surprised at the number of string based matches for subcommand rather than parsing into an enum early on.

The builder::Kind enum seems like it could work, but it's missing variants for Format, Clean, and Setup. flags::Subcommand is essentially what we're mapping on, but that enum has data associated with each variant that isn't built until after the subcommand type is known.

Here's a general idea for one way this could be refactored

enum SubcommandKind {
    Build,
    Check,
    ...
}
impl FromStr for SubcommandKind {...}
impl SubcommandKind {
    fn add_extra_opts(&self, opts: &mut Options) { /* flags.rs lines 279-338 */}
    fn add_extra_help(&self, subcommand_help: &mut String) { /* flags.rs lines 397-539 */ }
    fn build_subcommand(&self, paths: Vec<PathBuf>, matches: &Matches) -> Result<Subcommand> {
        /* flags.rs lines 550-624 */
    }
}

Pros of this: matching on an enum rather than string names of the commands, splitting up the very long Flags::parse() function so it's not over 500 lines long. Cons: large diff from moving so much code around may be undesirable, and now there's 3 different enums that have variants like Build, Check, Test, etc. which could be confusing.

The builder::Kind enum seems like it could work, but it's missing variants for Format, Clean, and Setup.

I think just adding the new variants will be simpler than trying to introduce a new type. Are you interested in working on that? I'm happy to mentor :)