This comment -- "by default we ignore everything in the repository" --
was added in rust-lang#65939 when rustfmt was first being introduced for this
repository and (briefly) every directory was ignored. Since then lots of
directories have opted in to formatting, so it is no longer true.

Some are too long, some aren't complete sentences, some are complete
sentences but don't bother with an upper case letter at the start. All
annoying and hurt readability.

It's reasonable to want to, but in the current implementation this
causes multiple problems.

- All the `rmake.rs` files are formatted every time even when they
  haven't changed. This is because they get whitelisted unconditionally
  in the `OverrideBuilder`, before the changed files get added.

- The way `OverrideBuilder` works, if any files gets whitelisted then no
  unmentioned files will get traversed. This is surprising, and means
  that the `rmake.rs` entries broke the use of explicit paths to `x
  fmt`, and also broke `GITHUB_ACTIONS=true git check --fmt`.

The commit removes the `rmake.rs` entries, fixes the formatting of a
couple of files that were misformatted (not previously caught due to the
`GITHUB_ACTIONS` breakage), and bans `!`-prefixed entries in
`rustfmt.toml` because they cause all these problems.

…ct, r=davidtwco

NVPTX: Avoid PassMode::Direct for args in C abi

Fixes rust-lang#117480

I must admit that I'm confused about `PassMode` altogether, is there a good sum-up threads for this anywhere? I'm especially confused about how "indirect" and "byval" goes together. To me it seems like "indirect" basically means "use a indirection through a pointer", while "byval" basically means "do not use indirection through a pointer".

The return used to keep `PassMode::Direct` for small aggregates. It turns out that `make_indirect` messes up the tests and one way to fix it is to keep `PassMode::Direct` for all aggregates. I have mostly seen this PassMode mentioned for args. Is it also a problem for returns? When experimenting with `byval` as an alternative i ran into [this assert](https://github.com/rust-lang/rust/blob/61a3eea8043cc1c7a09c2adda884e27ffa8a1172/compiler/rustc_codegen_llvm/src/abi.rs#L463C22-L463C22)

I have added tests for the same kind of types that is already tested for the "ptx-kernel" abi. The tests cannot be enabled until something like rust-lang#117458 is completed and merged.

CC: `@RalfJung` since you seem to be the expert on this and have already helped me out tremendously

CC: `@RDambrosio016` in case this influence your work on `rustc_codegen_nvvm`

`@rustbot` label +O-NVPTX

Add an intrinsic for `ptr::metadata`

The follow-up to rust-lang#123840, so we can remove `PtrComponents` and `PtrRepr` from libcore entirely (well, after a bootstrap update).

As discussed in <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/.60ptr_metadata.60.20in.20MIR/near/435637808>, this introduces `UnOp::PtrMetadata` taking a raw pointer and returning the associated metadata value.

By no longer going through a `union`, this should also help future PRs better optimize pointer operations.

r? `@oli-obk`

…ngs-cmdline-stability, r=jieyouxu

Migrate `run-make/allow-warnings-cmdline-stability` to `rmake.rs`

Part of rust-lang#121876.

r? `@jieyouxu`

Add a "Setup Python" action for github-hosted runners and remove unnecessary `CUSTOM_MINGW` environment variable

The Setup Python action isn't strictly necessary ([even on Windows](rust-lang#125584)) but it is [recommend by GitHub](https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#specifying-a-python-version).

The `CUSTOM_MINGW` environment variable is redundant now as it's always set for mingw and always unset otherwise.

try-job: x86_64-mingw
try-job: x86_64-mingw
try-job: dist-x86_64-msvc
try-job: dist-x86_64-mingw

…, r=lcnr

Make `ProofTreeBuilder` actually generic over `Interner`

Self-explanatory. Also renamed `ecx.tcx()` to `ecx.interner()`.

r? lcnr

…aumeGomez

rustfmt fixes

The `rmake.rs` entries in `rustfmt.toml` are causing major problems for `x fmt`. This PR removes them and does some minor related cleanups.

r? `@GuillaumeGomez`