opts: rephrase wording for --all and -p

[lnicola]

Tiny wording change as discussed in #3911.

[topecongiro]

Thank you for the PR! LGTM. And @calebcartwright thank you for reviewing this.

[jplatte]

Is it expected that this change has not made it to current versions of rustfmt?

$ cargo +nightly fmt --version
rustfmt 1.4.37-nightly (0bd2b19 2021-04-03)
$ cargo +nightly fmt --help
cargo-fmt 1.4.37
This utility formats all bin and lib files of the current crate using rustfmt.

USAGE:
    cargo fmt [FLAGS] [OPTIONS] [-- <rustfmt_options>...]

FLAGS:
        --all        Format all packages (only usable in workspaces)
    -h, --help       Prints help information
    -q, --quiet      No output printed to stdout
    -v, --verbose    Use verbose output
        --version    Print rustfmt version and exit

OPTIONS:
        --manifest-path <manifest-path>      Specify path to Cargo.toml
        --message-format <message-format>    Specify message-format: short|json|human
    -p, --package <package>...               Specify package to format (only usable in workspaces)

ARGS:
    <rustfmt_options>...    Options passed to rustfmt

[lnicola]

@topecongiro do you know where my commit went? https://github.com/rust-lang/rustfmt/blame/master/src/cargo-fmt/main.rs

[calebcartwright]

Is it expected that this change has not made it to current versions of rustfmt?

Expected, yes. Desired, no.

do you know where my commit went?

I need to find a way to explain this in one place to point back to since this pops up fairly frequently.

There were previously exploratory plans for a major/breaking v2.0 of rustfmt, and that work was being developed on the default master branch in this repository. That version of the code was never released in any capacity, and the work/codebase for the actual supported/released/official version of rustfmt was simultaneously occurring in various topic branches. A handful of the changes made to the v2 version were backported/cherry-picked over to a true release branch over those years and made their way out to users, but many have not.

I decided that given the actual release train for rustfmt (and the fact that a breaking release would not be happening any time soon, if ever), that branching strategy no longer made sense. Accordingly not too terribly long ago we switched back to using the default/master branch to reflect the actual 1.x version of rustfmt that's been released, and the 2.0 experiment was moved to a new topic branch (refs #4801)

You can see this reflected for the commit from this PR (c1ada05) which can be found on that 2.0 experiment branch, rustfmt-2.0.0-rc.2. I've also been trying to go back through and label issues/PRs accordingly (e.g. 1x-backport:pending) to reflect those which were made to 2.0 but not yet backported. However, that's a slow, tedious process given the volume and covered time window and #3911 was one such issue that hadn't yet been labeled.

Ultimately we need to get such commits backported into the current mainline. Occasionally that's as easy as a non-conflicting cherry-pick, but in many cases the two versions of the codebase had diverged so much that it's rather difficult. Commits against the 2.0 version also have to be re-evaluated against stability concerns, since the 2.0 major version bump didn't have to worry about breaking formatting changes.

[lnicola]

Thanks for the explanation, it makes sense. Do you mind if I file another PR with the same change? It's trivial and it shouldn't hurt. I'll do that tomorrow.

[calebcartwright]

Do you mind if I file another PR with the same change? It's trivial and it shouldn't hurt. I'll do that tomorrow.

Absolutely, please and thank you 😄 There's a lot of work needed to get things backported so anything that helps with that is most appreciated

[lnicola]

Done in #4989