Format all source files in `tests/coverage/`
Currently we can't automatically enforce formatting on tests (see #125637), but we can at least keep things relatively tidy by occasionally running the formatter manually.
This was done by temporarily commenting out the `"/tests/"` exclusion in `rustfmt.toml`, and then running:
- `x fmt tests/coverage`
- `x test coverage --bless`
(This PR also includes a few cosmetic tweaks to some of the affected files, to convince rustfmt to format them in the way we want.)
``@rustbot`` label +A-code-coverage
Use `rmake` for `windows-` run-make tests
Convert some Makefile tests to recipes.
I renamed "issue-85441" to "windows-ws2_32" as I think it's slightly more descriptive. EDIT: `llvm-readobj` seems to work for reading DLL imports so I've used that instead of `objdump`.
cc #121876
We want to only demand that we check for all components we expect
if we actually built the components we expect, which means
we built the LLVM. Otherwise, it isn't worth checking.
Make lint: `lint_dropping_references` `lint_forgetting_copy_types` `lint_forgetting_references` give suggestion if possible.
This is a follow-up PR of #125433. When it's merged, I want change lint `dropping_copy_types` to use the same `Subdiagnostic` struct `UseLetUnderscoreIgnoreSuggestion` which is added in this PR.
Hi, Thank you(`@Urgau` ) again for your help in the previous PR. If your time permits, please also take a look at this one.
r? compiler
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
don't inhibit random field reordering on repr(packed(1))
`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).
We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.
This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):
> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
don't inhibit random field reordering on repr(packed(1))
`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).
We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.
This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):
> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
If we perform this subtraction and then add 1, the subtraction can sometimes
overflow to -1 before the addition can bring its value back to 0. That
behaviour seems to be benign, but it nevertheless causes test failures in
compiler configurations that check for overflow.
We can avoid the overflow by instead subtracting (N - 1), which is
algebraically equivalent, and more closely matches what the code is actually
trying to do.
Currently, `x fmt` can print two lists of files.
- The untracked files that are skipped. Always done if within a git
repo.
- The modified files that are formatted.
But if you run with `--all` (or with `GITHUB_ACTIONS=true`) it doesn't
print anything about which files are formatted.
This commit increases consistency.
- The formatted/checked files are now always printed. And it makes it clear why
a file was formatted, e.g. with "modified".
- It uses the same code for both untracked files and formatted/checked
files. This means that now if there are a lot of untracked files just
the number will be printed, which is like the old behaviour for
modified files.
Example output:
```
fmt: skipped 31 untracked files
fmt: formatted modified file compiler/rustc_mir_transform/src/instsimplify.rs
fmt: formatted modified file compiler/rustc_mir_transform/src/validate.rs
fmt: formatted modified file library/core/src/ptr/metadata.rs
fmt: formatted modified file src/bootstrap/src/core/build_steps/format.rs
```
or (with `--all`):
```
fmt: checked 3148 files
```
- Precede them all with `fmt` so it's clear where they are coming from.
- Use `error:` and `warning:` when appropriate.
- Print warnings to stderr instead of stdout
