deal with `const_evaluatable_checked` in `ConstEquate`
Failing to evaluate two constants which do not contain inference variables should not result in ambiguity.
Bump bootstrap compiler to beta 1.53.0
This PR bumps the bootstrap compiler to version 1.53.0 beta, as part of our usual release process (this was supposed to be Wednesday's step, but creating the beta release took longer than expected).
The PR also includes the "Bootstrap: skip rustdoc fingerprint for building docs" commit, see the reasoning [on Zulip](https://zulip-archive.rust-lang.org/241545trelease/88450153betabootstrap.html).
r? `@Mark-Simulacrum`
Extend `rustc_on_implemented` to improve more `?` error messages
`_Self` could match the generic definition; this adds that functionality for matching the generic definition of type parameters too.
Your advice welcome on the wording of all these messages, and which things belong in the message/label/note.
r? `@estebank`
Always produce sub-obligations when using cached projection result
See https://github.com/rust-lang/rust/issues/85360
When we skip adding the sub-obligations to the `obligation` list, we can affect whether or not the final result is `EvaluatedToOk` or `EvaluatedToOkModuloObligations`. This creates problems for incremental compilation, since the projection cache is untracked shared state.
To solve this issue, we unconditionally process the sub-obligations. Surprisingly, this is a slight performance *win* in many cases.
Suggest borrowing if a trait implementation is found for &/&mut <type>
This pull request fixes#84973 by suggesting to borrow if a trait is not implemented for some type `T`, but it is for `&T` or `&mut T`. For instance:
```rust
trait Ti {}
impl<T> Ti for &T {}
fn foo<T: Ti>(_: T) {}
trait Tm {}
impl<T> Tm for &mut T {}
fn bar<T: Tm>(_: T) {}
fn main() {
let a: i32 = 5;
foo(a);
let b: Box<i32> = Box::new(42);
bar(b);
}
```
gives, on current nightly:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
--> t2.rs:11:9
|
3 | fn foo<T: Ti>(_: T) {}
| -- required by this bound in `foo`
...
11 | foo(a);
| ^ the trait `Ti` is not implemented for `i32`
error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
--> t2.rs:14:9
|
7 | fn bar<T: Tm>(_: T) {}
| -- required by this bound in `bar`
...
14 | bar(b);
| ^ the trait `Tm` is not implemented for `Box<i32>`
error: aborting due to 2 previous errors
```
whereas with my changes, I get:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
--> t2.rs:11:9
|
3 | fn foo<T: Ti>(_: T) {}
| -- required by this bound in `foo`
...
11 | foo(a);
| ^
| |
| expected an implementor of trait `Ti`
| help: consider borrowing here: `&a`
error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
--> t2.rs:14:9
|
7 | fn bar<T: Tm>(_: T) {}
| -- required by this bound in `bar`
...
14 | bar(b);
| ^
| |
| expected an implementor of trait `Tm`
| help: consider borrowing mutably here: `&mut b`
error: aborting due to 2 previous errors
```
In my implementation, I have added a "blacklist" to make these suggestions flexible. In particular, suggesting to borrow can interfere with other suggestions, such as to add another trait bound to a generic argument. I have tried to configure this blacklist to cause the least amount of test case failures, i.e. to model the current behavior as closely as possible (I only had to change one existing test case, and this change was quite clearly an improvement).
This adds a new lint to `rustc` that is used in rustdoc when a code
block is empty or cannot be parsed as valid Rust code.
Previously this was unconditionally a warning. As such some
documentation comments were (unknowingly) abusing this to pass despite
the `-Dwarnings` used when compiling `rustc`, this should not be the
case anymore.
Remove CrateNum parameter for queries that only work on local crate
The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea.
Using `()` as query key in those cases avoids having to worry about the validity of the query key.
Rework `on_completion` method so that it removes all
provisional cache entries that are "below" a completed
node (while leaving those entries that are not below
the node).
This corrects an imprecise result that could in turn lead
to an incremental compilation failure. Under the old
scheme, if you had:
* A depends on...
* B depends on A
* C depends on...
* D depends on C
* T: 'static
then the provisional results for A, B, C, and D would all
be entangled. Thus, if A was `EvaluatedToOkModuloRegions`
(because of that final condition), then the result for C and
D would also be demoted to "ok modulo regions".
In reality, though, the result for C depends only on C and itself,
and is not dependent on regions. If we happen to evaluate the
cycle starting from C, we would never reach A, and hence the
result would be "ok".
Under the new scheme, the provisional results for C and D
are moved to the permanent cache immediately and are not affected
by the result of A.
Deduplicate ParamCandidates with the same value except for bound vars
Fixes#84398
This is kind of a hack. I wonder if we can get other types of candidates that are the same except for bound vars. This won't be a problem with Chalk, since we don't really need to know that there are two different "candidates" if they both give the same final substitution.
r? `@nikomatsakis`
Add more info for common trait resolution and async/await errors
* Suggest `Pin::new`/`Box::new`/`Arc::new`/`Box::pin` in more cases
* Point at `impl` and type defs introducing requirements on E0277
normalize mir::Constant differently from ty::Const in preparation for valtrees
Valtrees are unable to represent many kind of constant values (this is on purpose). For constants that are used at runtime, we do not need a valtree representation and can thus use a different form of evaluation. In order to make this explicit and less fragile, I added a `fold_constant` method to `TypeFolder` and implemented it for normalization. Normalization can now, when it wants to eagerly evaluate a constant, normalize `mir::Constant` directly into a `mir::ConstantKind::Val` instead of relying on the `ty::Const` evaluation.
In the future we can get rid of the `ty::Const` in there entirely and add our own `Unevaluated` variant to `mir::ConstantKind`. This would allow us to remove the `promoted` field from `ty::ConstKind::Unevaluated`, as promoteds can never occur in the type system.
cc `@rust-lang/wg-const-eval`
r? `@lcnr`
