Remove path choice from `x fmt` and add `--all` option.

By default, `x fmt` formats/checks modified files. But it also lets you
choose one or more paths instead.

This adds significant complexity to `x fmt`. Explicit paths are
specified via `WalkBuilder::add` rather than `OverrideBuilder::add`. The
`ignore` library is not simple, and predicting the interactions between
the two mechanisms is difficult.

Here's a particularly interesting case.
- You can request a path P that is excluded by the `ignore` list in the
  `rustfmt.toml`. E.g. `x fmt tests/ui/` or `x fmt tests/ui/bitwise.rs`.
- `x fmt` will add P to the walker (via `WalkBuilder::add`), traverse it
  (paying no attention to the `ignore` list from the `rustfmt.toml`
  file, due to the different mechanism), and call `rustfmt` on every
  `.rs` file within it.
- `rustfmt` will do nothing to those `.rs` files, because it *also*
  reads `rustfmt.toml` and sees that they match the `ignore` list!

It took me *ages* to debug and understand this behaviour. Not good!

`x fmt` even lets you name a path below the current directory. This was
intended to let you do things like `x fmt std` that mirror things like
`x test std`. This works by looking for `std` and finding `library/std`,
and then formatting that. Unfortuantely, this motivating case now gives
an error. When support was added in #107944, `library/std` was the only
directory named `std`. Since then, `tests/ui/std` was added, and so `x
fmt std` now gives an error.

In general, explicit paths don't seem particularly useful. The only two
cases `x fmt` really needs are:
- format/check the files I have modified (99% of uses)
- format/check all files

(While respecting the `ignore` list in `rustfmt.toml`, of course.)

So this commit moves to that model. `x fmt` will now give an error if
given an explicit path. `x fmt` now also supports a `--all` option. (And
running with `GITHUB_ACTIONS=true` also causes everything to be
formatted/checked, as before.) Much simpler!

0 files changed, 0 insertions, 0 deletions