Use `edition = "2024"` in the compiler (redux)
Most of this is binding mode changes, which I fixed by running `x.py fix`.
Also adds some miscellaneous `unsafe` blocks for new unsafe standard library functions (the setenv ones), and a missing `unsafe extern` block in some enzyme codegen code, and fixes some precise capturing lifetime changes (but only when they led to errors).
cc ``@ehuss`` ``@traviscross``
Simplify slice indexing in next trait solver
Unless I'm missing something:
- no need to explicitly specify the end of the slice as the end of the index range
- the `assert` is redundant since the indexing will panic for the same condition
I think this change simplifies it a bit. Also replaced the `for` loop of `push`es with a call to `extend` with an iterator. Might improve performance since it knows how many elements will be added beforehand and can pre-reserve room?
r? `@compiler-errors` , I think
handle global trait bounds defining assoc types
This also fixes the compare-mode for
- tests/ui/coherence/coherent-due-to-fulfill.rs
- tests/ui/codegen/mono-impossible-2.rs
- tests/ui/trivial-bounds/trivial-bounds-inconsistent-projection.rs
- tests/ui/nll/issue-61320-normalize.rs
I first considered the alternative to always prefer where-bounds during normalization, regardless of how the trait goal has been proven by changing `fn merge_candidates` instead. ecda83b30f/compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs (L785)
This approach is more restrictive than behavior of the old solver to avoid mismatches between trait and normalization goals. This may be breaking in case the where-bound adds unnecessary region constraints and we currently don't ever try to normalize an associated type. I would like to detect these cases and change the approach to exactly match the old solver if required. I want to minimize cases where attempting to normalize in more places causes code to break.
r? `@compiler-errors`
If a type has unsafe fields, its safety invariants are not simply
the conjunction of its field types' safety invariants. Consequently,
it's invalid to reason about the safety properties of these types
in a purely structural manner — i.e., the manner in which `auto`
traits are implemented.
Makes progress towards #132922.
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
Allow dropping dyn principal
Revival of #126660, which was a revival of #114679. Fixes#126313.
Allows dropping principal when coercing trait objects, e.g. `dyn Debug + Send` -> `dyn Send`.
cc `@compiler-errors` `@Jules-Bertholet`
r? `@lcnr`
Introduce SolverRelating type relation to the new solver
Redux of #128744.
Splits out relate for the new solver so that implementors don't need to implement it themselves.
r? lcnr
add caching to most type folders, rm region uniquification
Fixes the new minimization of the hang in nalgebra and nalgebra itself :3
this is a bit iffy, especially the cache in `TypeRelating`. I believe all the caches are correct, but it definitely adds some non-local complexity in places. The first commit removes region uniquification, reintroducing the ICE from https://github.com/rust-lang/trait-system-refactor-initiative/issues/27. This does not affect coherence and I would like to fix this by introducing OR-region constraints
r? `@compiler-errors`
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
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``
Fix `clippy::useless_conversion`
Self-explanatory. Probably the last clippy change I'll actually put up since this is the only other one I've actually seen in the wild.
