Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup
Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.
Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.
---
Old terminology (HIR, rustdoc):
```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
├── `Ty`: (associated) type binding
└── `Const`: associated const equality (constraint)
```
Old terminology (AST, abbrev.):
```
`AssocConstraint`
├── `Bound`
└── `Equality`
├── `Ty`
└── `Const`
```
New terminology (AST, HIR, rustdoc):
```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
├── `Ty`: associated type equality constraint OR associated type binding (for short)
└── `Const`: associated const equality constraint OR associated const binding (for short)
```
r? compiler-errors
compiletest: clarify COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS error
COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS is a confusing name because elsewhere "needs" means "ignore when requirement not met", but here it means "fail when requirement not met".
remove tracing tree indent lines
This allows vscode to collapse nested spans without having to manually remove the indent lines. This is incredibly useful when logging the new solver. I don't mind making them optional depending on some environment flag if you prefer using indent lines
For a gist of the new output, see https://gist.github.com/lcnr/bb4360ddbc5cd4631f2fbc569057e5eb#file-example-output-L181
r? `@oli-obk`
compiletest: Unify `cmd2procres` with `run_command_to_procres`
Historical context: I originally added `run_command_to_procres` in #112300 and #114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code.
Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
drop_in_place: weaken the claim of equivalence with drop(ptr.read())
The two are *not* semantically equivalent in all cases, so let's not be so definite about this.
Fixes https://github.com/rust-lang/rust/issues/112015
Make `body_owned_by` return the `Body` instead of just the `BodyId`
fixes#125677
Almost all `body_owned_by` callers immediately called `body`, too, so just return `Body` directly.
This makes the inline-const query feeding more robust, as all calls to `body_owned_by` will now yield a body for inline consts, too.
I have not yet figured out a good way to make `tcx.hir().body()` return an inline-const body, but that can be done as a follow-up
Streamline `x fmt` and improve its output
- Removes the ability to pass paths to `x fmt`, because it's complicated and not useful, and adds `--all`.
- Improves `x fmt` output.
- Improves `x fmt`'s internal code.
r? ``@GuillaumeGomez``
Rollup of 7 pull requests
Successful merges:
- #124655 (Add `-Zfixed-x18`)
- #125693 (Format all source files in `tests/coverage/`)
- #125700 (coverage: Avoid overflow when the MC/DC condition limit is exceeded)
- #125705 (Reintroduce name resolution check for trying to access locals from an inline const)
- #125708 (tier 3 target policy: clarify the point about producing assembly)
- #125715 (remove unneeded extern crate in rmake test)
- #125719 (Extract coverage-specific code out of `compiletest::runtest`)
r? `@ghost`
`@rustbot` modify labels: rollup
Extract coverage-specific code out of `compiletest::runtest`
I had been vaguely intending to do this for a while, but seeing #89475 on the compiletest dashboard inspired me to actually go and do it.
This moves a few hundred lines of coverage-specific code out of the main module, making navigation a bit easier. There is still a small amount of coverage-specific logic in broader functions in that module, since it can't easily be moved.
This is just cut-and-paste plus fixing visibility and imports, so no functional changes.
I also removed the unit test for anonymizing line numbers in MC/DC reports, as foreshadowed by the comment I wrote when adding it. That functionality is now adequately exercised by the actual snapshot tests for MC/DC coverage.
(Removing the test now avoids the need to move it, or to make the function it calls visible.)
tier 3 target policy: clarify the point about producing assembly
I think that is already the intended meaning of the policy, but I am not sure.
Cc ``@rust-lang/compiler``
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.
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.
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
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!
