Make opaque types regular HIR nodes
Having opaque types as HIR owner introduces all sorts of complications. This PR proposes to make them regular HIR nodes instead.
I haven't gone through all the test changes yet, so there may be a few surprises.
Many thanks to `@camelid` for the first draft.
Fixes https://github.com/rust-lang/rust/issues/129023Fixes#129099Fixes#125843Fixes#119716Fixes#121422
Account for `impl Trait {` when `impl Trait for Type {` was intended
On editions where bare traits are never allowed, detect if the user has written `impl Trait` with no type, silence any dyn-compatibility errors, and provide a structured suggestion for the potentially missing type:
```
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/missing-for-type-in-impl.rs:8:6
|
LL | impl Foo<i64> {
| ^^^^^^^^
|
help: add `dyn` keyword before this trait
|
LL | impl dyn Foo<i64> {
| +++
help: you might have intended to implement this trait for a given type
|
LL | impl Foo<i64> for /* Type */ {
| ++++++++++++++
```
CC #131051.
On editions where bare traits are never allowed, detect if the user has
written `impl Trait` with no type, silence any dyn-compatibility errors,
and provide a structured suggestion for the potentially missing type:
```
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/missing-for-type-in-impl.rs:8:6
|
LL | impl Foo<i64> {
| ^^^^^^^^
|
help: add `dyn` keyword before this trait
|
LL | impl dyn Foo<i64> {
| +++
help: you might have intended to implement this trait for a given type
|
LL | impl Foo<i64> for /* Type */ {
| ++++++++++++++
```
Stabilize the `map`/`value` methods on `ControlFlow`
And fix the stability attribute on the `pub use` in `core::ops`.
libs-api in https://github.com/rust-lang/rust/issues/75744#issuecomment-2231214910 seemed reasonably happy with naming for these, so let's try for an FCP.
Summary:
```rust
impl<B, C> ControlFlow<B, C> {
pub fn break_value(self) -> Option<B>;
pub fn map_break<T>(self, f: impl FnOnce(B) -> T) -> ControlFlow<T, C>;
pub fn continue_value(self) -> Option<C>;
pub fn map_continue<T>(self, f: impl FnOnce(C) -> T) -> ControlFlow<B, T>;
}
```
Resolves#75744
``@rustbot`` label +needs-fcp +t-libs-api -t-libs
---
Aside, in case it keeps someone else from going down the same dead end: I looked at the `{break,continue}_value` methods and tried to make them `const` as part of this, but that's disallowed because of not having `const Drop`, so put it back to not even unstably-const.
Implement RFC3695 Allow boolean literals as cfg predicates
This PR implements https://github.com/rust-lang/rfcs/pull/3695: allow boolean literals as cfg predicates, i.e. `cfg(true)` and `cfg(false)`.
r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
Refactoring to `OpaqueTyOrigin`
Pulled out of a larger PR that uses these changes to do cross-crate encoding of opaque origin, so we can use them for edition 2024 migrations. These changes should be self-explanatory on their own, tho 😄
Allow instantiating object trait binder when upcasting
This PR fixes two bugs (that probably need an FCP).
### We use equality rather than subtyping for upcasting dyn conversions
This code should be valid:
```rust
#![feature(trait_upcasting)]
trait Foo: for<'h> Bar<'h> {}
trait Bar<'a> {}
fn foo(x: &dyn Foo) {
let y: &dyn Bar<'static> = x;
}
```
But instead:
```
error[E0308]: mismatched types
--> src/lib.rs:7:32
|
7 | let y: &dyn Bar<'static> = x;
| ^ one type is more general than the other
|
= note: expected existential trait ref `for<'h> Bar<'h>`
found existential trait ref `Bar<'_>`
```
And so should this:
```rust
#![feature(trait_upcasting)]
fn foo(x: &dyn for<'h> Fn(&'h ())) {
let y: &dyn FnOnce(&'static ()) = x;
}
```
But instead:
```
error[E0308]: mismatched types
--> src/lib.rs:4:39
|
4 | let y: &dyn FnOnce(&'static ()) = x;
| ^ one type is more general than the other
|
= note: expected existential trait ref `for<'h> FnOnce<(&'h (),)>`
found existential trait ref `FnOnce<(&(),)>`
```
Specifically, both of these fail because we use *equality* when comparing the supertrait to the *target* of the unsize goal. For the first example, since our supertrait is `for<'h> Bar<'h>` but our target is `Bar<'static>`, there's a higher-ranked type mismatch even though we *should* be able to instantiate that supertrait binder when upcasting. Similarly for the second example.
### New solver uses equality rather than subtyping for no-op (i.e. non-upcasting) dyn conversions
This code should be valid in the new solver, like it is with the old solver:
```rust
// -Znext-solver
fn foo<'a>(x: &mut for<'h> dyn Fn(&'h ())) {
let _: &mut dyn Fn(&'a ()) = x;
}
```
But instead:
```
error: lifetime may not live long enough
--> <source>:2:11
|
1 | fn foo<'a>(x: &mut dyn for<'h> Fn(&'h ())) {
| -- lifetime `'a` defined here
2 | let _: &mut dyn Fn(&'a ()) = x;
| ^^^^^^^^^^^^^^^^^^^ type annotation requires that `'a` must outlive `'static`
|
= note: requirement occurs because of a mutable reference to `dyn Fn(&())`
```
Specifically, this fails because we try to coerce `&mut dyn for<'h> Fn(&'h ())` to `&mut dyn Fn(&'a ())`, which registers an `dyn for<'h> Fn(&'h ()): dyn Fn(&'a ())` goal. This fails because the new solver uses *equating* rather than *subtyping* in `Unsize` goals.
This is *mostly* not a problem... You may wonder why the same code passes on the new solver for immutable references:
```
// -Znext-solver
fn foo<'a>(x: &dyn Fn(&())) {
let _: &dyn Fn(&'a ()) = x; // works
}
```
That's because in this case, we first try to coerce via `Unsize`, but due to the leak check the goal fails. Then, later in coercion, we fall back to a simple subtyping operation, which *does* work.
Since `&T` is covariant over `T`, but `&mut T` is invariant, that's where the discrepancy between these two examples crops up.
---
r? lcnr or reassign :D
Introduce `structurally_normalize_const`, use it in `rustc_hir_typeck`
Introduces `structurally_normalize_const` to typecking to separate the "eval a const" step from the "try to turn a valtree into a target usize" in HIR typeck, where we may still have infer vars and stuff around.
I also changed `check_expr_repeat` to move a double evaluation of a const into a single one. I'll leave inline comments.
r? ```@BoxyUwU```
I hesitated to really test this on the new solver where it probably matters for unevaluated consts. If you're worried about the side-effects, I'd be happy to craft some more tests 😄
Don't call `ty::Const::normalize` in error reporting
We do this to ensure that trait refs with unevaluated consts have those consts simplified to their evaluated forms. Instead, use `try_normalize_erasing_regions`.
**NOTE:** This has the side-effect of erasing regions from all of our trait refs. If this is too much to review or you think it's too opinionated of a diagnostics change, then I could split out the effective change (i.e. erasing regions from this impl suggestion) into another PR and have someone else review it.
Correct outdated object size limit
The comment here about 48 bit addresses being enough was written in 2016 but was made incorrect in 2019 by 5-level paging, and then persisted for another 5 years before being noticed and corrected.
The bolding of the "exclusive" part is merely to call attention to something I missed when reading it and doublechecking the math.
try-job: i686-msvc
try-job: test-various
Implement a Method to Seal `DiagInner`'s Suggestions
This PR adds a method on `DiagInner` called `.seal_suggestions()` to prevent new suggestions from being added while preserving existing suggestions.
This is useful because currently there is no way to prevent new suggestions from being added to a diagnostic. `.disable_suggestions()` is the closest but it gets rid of all suggestions before and after the call.
Therefore, `.seal_suggestions()` can be used when, for example, misspelled keyword is detected and reported. In such cases, we may want to prevent other suggestions from being added to the diagnostic, as they would likely be meaningless once the misspelled keyword is identified. For context: https://github.com/rust-lang/rust/pull/129899#discussion_r1741307132
To store an additional state, the type of the `suggestions` field in `DiagInner` was changed into a three variant enum. While this change affects files across different crates, care was taken to preserve the existing code's semantics. This is validated by the fact that all UI tests pass without any modifications.
r? chenyukang
Don't call `extern_crate` when local crate name is the same as a dependency and we have a trait error
#124944 implemented logic to point out when a trait bound failure involves a *trait* and *type* who come from identically named but different crates. This logic calls the `extern_crate` query which is not valid on `LOCAL_CRATE` cnum, so let's filter that out eagerly.
Fixes#130272Fixes#129184
(fix) conflicting negative impl marker
## Context
This MR fixes the error message for conflicting negative trait impls by adding the corresponding the polarity marker to the trait name.
## Issues
- closes#70849
r? `@fmease`
- Replace non-standard names like 's, 'p, 'rg, 'ck, 'parent, 'this, and
'me with vanilla 'a. These are cases where the original name isn't
really any more informative than 'a.
- Replace names like 'cx, 'mir, and 'body with vanilla 'a when the lifetime
applies to multiple fields and so the original lifetime name isn't
really accurate.
- Put 'tcx last in lifetime lists, and 'a before 'b.
more eagerly discard constraints on overflow
We always discard the results of overflowing goals inside of the trait solver. We previously did so when instantiating the response in `evaluate_goal`. Canonicalizing results only to later discard them is also inefficient 🤷
It's simpler and nicer to debug to eagerly discard constraints inside of the query itself.
r? ``@compiler-errors``
