Skip to content

Deeply normalize obligations in BestObligation folder #139564

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 11, 2025

Conversation

compiler-errors
Copy link
Member

Built on #139513.

This establishes a somewhat rough invariant that the Obligation's predicate is always deeply normalized in the folder; when we construct a new obligation we normalize it.

Putting this up for discussion since it does affect some goals.

r? lcnr

@rustbot
Copy link
Collaborator

rustbot commented Apr 9, 2025

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Apr 9, 2025
@@ -1,17 +1,9 @@
error[E0271]: type mismatch resolving `<dyn Trait<A = A, B = B> as SuperTrait>::A == B`
error[E0271]: type mismatch resolving `A == B`
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AliasRelate goals are negatively affected by this PR, which should make sense b/c we're normalizing the LHS and RHS; we probably should special-case ProjectionPredicates, since handling AliasRelate predicates is already kinda weird:

ty::PredicateKind::AliasRelate(lhs, rhs, _) => {
let derive_better_type_error =
|alias_term: ty::AliasTerm<'tcx>, expected_term: ty::Term<'tcx>| {
let ocx = ObligationCtxt::new(self);
let Ok(normalized_term) = ocx.structurally_normalize_term(
&ObligationCause::dummy(),
obligation.param_env,
alias_term.to_term(self.tcx),
) else {
return None;
};
if let Err(terr) = ocx.eq(
&ObligationCause::dummy(),
obligation.param_env,
expected_term,
normalized_term,
) {
Some((terr, self.resolve_vars_if_possible(normalized_term)))
} else {
None
}
};
if let Some(lhs) = lhs.to_alias_term()
&& let Some((better_type_err, expected_term)) =
derive_better_type_error(lhs, rhs)
{
(
Some((lhs, self.resolve_vars_if_possible(expected_term), rhs)),
better_type_err,
)
} else if let Some(rhs) = rhs.to_alias_term()
&& let Some((better_type_err, expected_term)) =
derive_better_type_error(rhs, lhs)
{
(
Some((rhs, self.resolve_vars_if_possible(expected_term), lhs)),
better_type_err,
)
} else {
(None, error.err)
}
.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm yeah, I feel like we should do the "alias-relate -> normalization failure" transformation in the BestObligation visitor instead maybe 🤔

This is definitely worse... also in the next-solver/async.rs#fail test

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather defer this to a different PR. Right now the regression seems like a logical consequence of this implementation, and I'll play around with a fix for the AliasRelate regression separately.

.unwrap_or_else(|_: Vec<ScrubbedTraitError<'tcx>>| ty.super_fold_with(self))
self.at
.infcx
.commit_if_ok(|_| {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commit_if_ok b/c we shouldn't apply inference/opaque side-effects if the nested goals don't hold.

@bors
Copy link
Collaborator

bors commented Apr 9, 2025

☔ The latest upstream changes (presumably #139555) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the idea is to deeply normalize the resulting obligations, but not deeply normalizing the goal we use to recur?

In that case, would it be easier to add a single deeply normalize call on the result of the visitor?

@compiler-errors
Copy link
Member Author

In that case, would it be easier to add a single deeply normalize call on the result of the visitor?

lol, I thought we didn't fold ObligationCauseCodes, but it seems like we do. Yeah, that's simpler then.

@lcnr
Copy link
Contributor

lcnr commented Apr 9, 2025

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Apr 9, 2025

📌 Commit 4192cb6 has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 9, 2025
@compiler-errors
Copy link
Member Author

@bors r- #139513 (comment)

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 9, 2025
@bors
Copy link
Collaborator

bors commented Apr 10, 2025

☔ The latest upstream changes (presumably #139595) made this pull request unmergeable. Please resolve the merge conflicts.

@compiler-errors
Copy link
Member Author

@bors r=lcnr

@bors
Copy link
Collaborator

bors commented Apr 11, 2025

📌 Commit decd7ec has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 11, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 11, 2025
Rollup of 12 pull requests

Successful merges:

 - rust-lang#137447 (add `core::intrinsics::simd::{simd_extract_dyn, simd_insert_dyn}`)
 - rust-lang#138182 (rustc_target: update x86_win64 to match the documented calling convention for f128)
 - rust-lang#138682 (Allow drivers to supply a list of extra symbols to intern)
 - rust-lang#138904 (Test linking and running `no_std` binaries)
 - rust-lang#138998 (Don't suggest the use of  `impl Trait` in closure parameter)
 - rust-lang#139447 (doc changes: debug assertions -> overflow checks)
 - rust-lang#139469 (Introduce a `//@ needs-crate-type` compiletest directive)
 - rust-lang#139564 (Deeply normalize obligations in `BestObligation` folder)
 - rust-lang#139574 (bootstrap: improve `channel` handling)
 - rust-lang#139600 (Update `compiler-builtins` to 0.1.153)
 - rust-lang#139641 (Allow parenthesis around inferred array lengths)
 - rust-lang#139654 (Improve `AssocItem::descr`.)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit d213934 into rust-lang:master Apr 11, 2025
6 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 11, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 11, 2025
Rollup merge of rust-lang#139564 - compiler-errors:deeply-norm, r=lcnr

Deeply normalize obligations in `BestObligation` folder

Built on rust-lang#139513.

This establishes a somewhat rough invariant that the `Obligation`'s predicate is always deeply normalized in the folder; when we construct a new obligation we normalize it.

Putting this up for discussion since it does affect some goals.

r? lcnr
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants