This commit can be replicated by running
`cargo update -p rustfix --precise 0.8.7 && x test ui --bless`.
---
The reasons this affects UI tests is as follows:
- The UI test suite runs rustc with
`-Z deduplicate-diagnostics=no --error-format=json`,
which means that rustc emits multiple errors containing identical
suggestions. That caused the weird-looking code that had multiple `X: Copy` suggestions.
- Those suggestions are interpreted not by rustc itself, but by the
`rustfix` library, maintained by cargo but published as a separate
crates.io library and used by compiletest.
- Sometime between rustfix 0.8.1 and 0.8.7 (probably in cargo 14747, but
it's hard to tell because rustfix's versioning doesn't match cargo's),
rustfix got smarter and stopped applying duplicate suggestions.
Update rustfix to match cargo's behavior. Ideally, we would always share
a version of rustfix between cargo and rustc (perhaps with a path
dependency?), to make sure we are testing the behavior we ship. But for
now, just manually update it to match.
Note that the latest version of rustfix published to crates.io is 0.9.1,
not 0.8.7. But 0.9.1 is not the version used in cargo, which is 0.9.3.
Rather than trying to match versions exactly, I just updated rustfix to
the latest in the 0.8 branch.
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#3 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
`tests/ui`: A New Order [12/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
Fix incorrect suggestion when calling an associated type with a type anchor
`sugg_span` here is the span of the call expression.
That span here is the `<Self>::Assoc`, which is exactly what we need here (even though I would expect it to include the arguments, but I guess it doesn't)
r? ``@WaffleLapkin``
One commit with failing tests and one that fixes it for reviewability
closesrust-lang/rust#142473
Improve diagnostics for usage of qualified paths within tuple struct exprs/pats
For patterns the old diagnostic was just incorrect, but I also added machine applicable suggestions.
For context, this special cases errors for `<T as Trait>::Assoc(..)` patterns and expressions (latter is just a call). Tuple struct patterns and expressions both live in the value namespace, so they are not forwarded through associated *types*.
r? ``@jdonszelmann``
cc ``@petrochenkov`` in https://github.com/rust-lang/rust/pull/80080#issuecomment-800630582 you were wondering why it doesn't work for types, that's why — tuple patterns are resolved in the value namespace.
Method errors have an extra check that force trim paths whenever the
normal string is longer than 10 characters, which can be quite unhelpful
when multiple items have the same name (for example an `Error`).
A user reported this force trimming as being quite unhelpful when they
had a method error where the precise path of the `Error` mattered.
The code uses `tcx.short_string` already to get the normal path, which
tries to be clever around trimming paths if necessary, so there is no
reason for this extra force trimming.
HIR ty lowering: Clean up & refactor the lowering of type-relative paths
While rebasing #126651 I realized that HIR ty lowering could benefit from some *spring cleaning* now that it's been extended to handle RTN and mGCA paths.
More seriously, similar to my merged PR #118668 which unified the handling of all *associated item constraints* (assoc ty, const (ACE) & fn (RTN)), this PR (commit 695fcf517d) partially[^1] deduplicates the resolution code for all *type-relative paths* (assoc ty, const (mGCA) & fn (RTN)).
**Why**? DRY'ing that part of the code means PR #126651 will automatically support RTN paths like `Ty::AssocTy::assoc_fn(..)` and it also implies shared diagnostic code and thus better diagnostics for RTN.
---
The other commits represent cleanups, renamings, moves. More notably, I've renamed path lowering methods to be a lot more descriptive, so ones lowering `QPath(Resolved)` paths now have `_resolved_` in their name and ones lowering `QPath(TypeRelative)` paths now have `_type_relative_` in their name. This should make it stupidly obvious what their purpose is.
---
Best reviewed commit by commit. The changes are close to trivial but the diff might make it look hairier.
r? compiler-errors
[^1]: Sadly, I couldn't unify as much compared to the other PR without introducing unnecessary `unreachable!()`s or rendering the code otherwise illegible with flags and micro helper traits.
Make well-formedness predicates no longer coinductive
This PR makes well-formedness no longer coinductive. It was made coinductive in https://github.com/rust-lang/rust/pull/98542, but AFAICT this was only to fix UI tests since we stopped lowering `where Ty:` to an empty-region outlives predicate but to a WF predicate instead.
Arguably it should lower to something completely different, something like a "type mentioned no-op predicate", but well-formedness serves this purpose fine today, and since no code (according to crater) relies on this coinductive behavior, we'd like to avoid having to emulate it in the new solver.
Fixes#123456 (I didn't want to add a test since it seems low-value to have a ICE test for a fuzzer minimization that is basically garbage code.)
Fixes#109764 (not sure if this behavior is emulatable w/o coinductive WF?)
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/169
r? lcnr
Stabilize `cfg_boolean_literals`
Closes#131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating
--
# Stabilization Report
## General design
### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
[RFC 3695](https://github.com/rust-lang/rfcs/pull/3695), none.
### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
None
### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
None
## Has a call-for-testing period been conducted? If so, what feedback was received?
Yes; only positive feedback was received.
## Implementation quality
### Summarize the major parts of the implementation and provide links into the code (or to PRs)
Implemented in [#131034](https://github.com/rust-lang/rust/pull/131034).
### Summarize existing test coverage of this feature
- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](6d71251cf9/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](6d71251cf9/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`
### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
The above mentioned issue; it should not block as it interacts with another unstable feature.
### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None
### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)
### Which tools need to be adjusted to support this feature. Has this work been done?
`rustdoc`'s unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.
## Type system and execution rules
### What updates are needed to the reference/specification? (link to PRs when they exist)
A few lines to be added to the reference for configuration predicates, specified in the RFC.
Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable`
See comments in code and in test I added.
r? `@BoxyUwU` since you reviewed the last PR, or reassign
Fixes#138937
tests: use minicore more
minicore makes it much easier to add new language items to all of the existing `no_core` tests.
Most of the remaining tests that *could* use minicore either fail because..
1. LLVM IR output changes and doesn't pass the test as written. I didn't look into these further.
2. The test has revisions w/ different compilation flags, expecting some to fail, and when using minicore, minicore is compiled with those flags and fails in the expected way because of the flags rather than the test, and that's considered a failure.
But these tests can be changed and make adding new language items a lot easier.
r? ```@jieyouxu```
