Auto merge of #121549 - matthiaskrgr:rollup-1hvu3lb, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #121435 (Account for RPITIT in E0310 explicit lifetime constraint suggestion)
 - #121490 (Rustdoc: include crate name in links for local primitives)
 - #121520 (delay cloning of iterator items)
 - #121522 (check that simd_insert/extract indices are in-bounds)
 - #121531 (Ignore less tests in debug builds)
 - #121539 (compiler/rustc_target/src/spec/base/apple/tests.rs: Avoid unnecessary large move)
 - #121542 (update stdarch)

r? `@ghost`
`@rustbot` modify labels: rollup
This commit is contained in:
bors 2024-02-24 21:08:39 +00:00
commit 381d69953b
76 changed files with 189 additions and 152 deletions

View file

@ -320,22 +320,25 @@ fn impl_intersection_has_impossible_obligation<'a, 'cx, 'tcx>(
let mut errors = fulfill_cx.select_where_possible(infcx);
errors.pop().map(|err| err.obligation)
} else {
obligations.iter().cloned().find(|obligation| {
// We use `evaluate_root_obligation` to correctly track intercrate
// ambiguity clauses. We cannot use this in the new solver.
let evaluation_result = selcx.evaluate_root_obligation(obligation);
obligations
.iter()
.find(|obligation| {
// We use `evaluate_root_obligation` to correctly track intercrate
// ambiguity clauses. We cannot use this in the new solver.
let evaluation_result = selcx.evaluate_root_obligation(obligation);
match evaluation_result {
Ok(result) => !result.may_apply(),
// If overflow occurs, we need to conservatively treat the goal as possibly holding,
// since there can be instantiations of this goal that don't overflow and result in
// success. This isn't much of a problem in the old solver, since we treat overflow
// fatally (this still can be encountered: <https://github.com/rust-lang/rust/issues/105231>),
// but in the new solver, this is very important for correctness, since overflow
// *must* be treated as ambiguity for completeness.
Err(_overflow) => false,
}
})
match evaluation_result {
Ok(result) => !result.may_apply(),
// If overflow occurs, we need to conservatively treat the goal as possibly holding,
// since there can be instantiations of this goal that don't overflow and result in
// success. This isn't much of a problem in the old solver, since we treat overflow
// fatally (this still can be encountered: <https://github.com/rust-lang/rust/issues/105231>),
// but in the new solver, this is very important for correctness, since overflow
// *must* be treated as ambiguity for completeness.
Err(_overflow) => false,
}
})
.cloned()
}
}