| Age | Commit message (Collapse) | Author | Lines |
|---|
|
PolyProjectionPredicate<'tcx>`
|
|
move required_consts check to general post-mono-check function
This factors some code that is common between the interpreter and the codegen backends into shared helper functions. Also as a side-effect the interpreter now uses the same `eval` functions as everyone else to get the evaluated MIR constants.
Also this is in preparation for another post-mono check that will be needed for (the current hackfix for) https://github.com/rust-lang/rust/issues/115709: ensuring that all locals are dynamically sized.
I didn't expect this to change diagnostics, but it's just cycle errors that change.
r? `@oli-obk`
|
|
|
|
inspect: closer to proof trees for coherence
a continuation of #115751. Now explicitly store the added goals
r? ```@compiler-errors```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
some inspect improvements
split from #114810 because I still want to experiment a bunch with that PR and these changes are self-contained.
r? `@compiler-errors`
|
|
Implement fallback for effect param
r? `@oli-obk` or `@lcnr`
tracking issue for this ongoing work: https://github.com/rust-lang/rust/issues/110395
|
|
also handle 2 panics when dumping proof trees for the whole test suite
- need to actually tell the proof tree builder about overflow
- need to handle a recursion_limit of 0 :<
|
|
|
|
|
|
the unnormalized goal is in the callers inference context, while
anything inside of the `CanonicalGoalEvaluation` is inside of
a new one.
|
|
|
|
Don't ICE on associated type projection without feature gate in new solver
Self-explanatory, we should avoid ICEs when the feature gate is not enabled. Continue to ICE when the feature gate *is* enabled, though.
Fixes #115500
|
|
Do not require associated types with Self: Sized to uphold bounds when confirming object candidate
RPITITs and associated types that have `Self: Sized` bounds are opted out of the `dyn Trait` well-formedness check that happens during confirmation. This ensures that we can actually *use* `dyn Trait`s that have associated types that, e.g., have GATs and RPITITs and other naughty things as long as those are opted-out of object safety via a `Self: Sized` bound.
Fixes #115464
This seems like a natural part of https://github.com/rust-lang/rust/pull/112319#issuecomment-1592574451, and I don't think needs re-litigation.
r? `@oli-obk`
|
|
|
|
confirming object candidate
|
|
|
|
remove the repetitive word
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
fixes bors snafu where it merged an outdated commit and missed this
change
|
|
|
|
this previously was a off-by-one error.
|
|
compiler-errors:next-solver-projection-subst-compat, r=lcnr
Check projection args before substitution in new solver
Don't ICE when an impl has the wrong kind of GAT arguments
r? lcnr
|
|
compiler-errors:next-solver-only-unsize-to-dyn-once, r=lcnr
Separate `consider_unsize_to_dyn_candidate` from other unsize candidates
Move the unsize candidate assembly *just for* `T -> dyn Trait` out of `assemble_candidates_via_self_ty` so that we only consider it once, instead of for every normalization step of the self ty. This makes sure that we don't assemble several candidates that are equal modulo normalization when we really don't care about normalizing the self type of an `T: Unsize<dyn Trait>` goal anyways.
Fixes rust-lang/trait-system-refactor-initiative#57
r? lcnr
|
|
Probe when assembling upcast candidates so they don't step on eachother's toes in new solver
Lack of a probe causes one candidate to disqualify the other due to inference side-effects.
r? lcnr
|
|
r=lcnr
Only consider object candidates for object-safe dyn types in new solver
We apparently allow this per RFC2027 :skull:
r? lcnr
|
|
|
|
|
|
|
|
|
|
|
|
normalize in `trait_ref_is_knowable` in new solver
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/51
Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further
I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.
r? `@compiler-errors`
|
|
|
|
|
|
|
|
|
|
r=oli-obk
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
|
|
Bubble up nested goals from equation in `predicates_for_object_candidate`
This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)
r? `@lcnr`
|
|
|
|
|
|
update overflow handling in the new trait solver
implements https://hackmd.io/QY0dfEOgSNWwU4oiGnVRLw?view. I want to clean up this doc and add it to the rustc-dev-guide, but I think this PR is ready for merge as is, even without the dev-guide entry.
r? `@compiler-errors`
|
|
Rework upcasting confirmation to support upcasting to fewer projections in target bounds
This PR implements a modified trait upcasting algorithm that is resilient to changes in the number of associated types in the bounds of the source and target trait objects.
It does this by equating each bound of the target trait ref individually against the bounds of the source trait ref, rather than doing them all together by constructing a new trait object.
#### The new way we do trait upcasting confirmation
1. Equate the target trait object's principal trait ref with one of the supertraits of the source trait object's principal.
https://github.com/rust-lang/rust/blob/fdcab310b2a57a4e9cc0b2629abd27afda49cd80/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2509-L2525
2. Make sure that every auto trait in the *target* trait object is present in the source trait ref's bounds.
https://github.com/rust-lang/rust/blob/fdcab310b2a57a4e9cc0b2629abd27afda49cd80/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2559-L2562
3. For each projection in the *target* trait object, make sure there is exactly one projection that equates with it in the source trait ref's bound. If there is more than one, bail with ambiguity.
https://github.com/rust-lang/rust/blob/fdcab310b2a57a4e9cc0b2629abd27afda49cd80/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2526-L2557
* Since there may be more than one that applies, we probe first to check that there is exactly one, then we equate it outside of a probe once we know that it's unique.
4. Make sure the lifetime of the source trait object outlives the lifetime of the target.
<details>
<summary>Meanwhile, this is how we used to do upcasting:</summary>
1. For each supertrait of the source trait object, take that supertrait, append the source object's projection bounds, and the *target* trait object's auto trait bounds, and make this into a new object type:
https://github.com/rust-lang/rust/blob/d12c6e947ceacf3b22c154caf9532b390d8dc88a/compiler/rustc_trait_selection/src/traits/select/confirmation.rs#L915-L929
2. Then equate it with the target trait object:
https://github.com/rust-lang/rust/blob/d12c6e947ceacf3b22c154caf9532b390d8dc88a/compiler/rustc_trait_selection/src/traits/select/confirmation.rs#L936
This will be a type mismatch if the target trait object has fewer projection bounds, since we compare the bounds structurally in relate:
https://github.com/rust-lang/rust/blob/d12c6e947ceacf3b22c154caf9532b390d8dc88a/compiler/rustc_middle/src/ty/relate.rs#L696-L698
</details>
Fixes #114035
Also fixes #114113, because I added a normalize call in the old solver.
r? types
|
|
|
|
|
|
|
|
|
