Don't probe InferConst in fold_const if self.infcx is None, deeply_normalize tys in check_tys_might_be_eq

[ShE3py]

Fixes #119381, fixes #114456.

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

changes to the core type system

cc @compiler-errors, @lcnr

[compiler-errors]

r? lcnr

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[ShE3py]

@rustbot label -A-testsuite -T-bootstrap
(typo fix)

[BoxyUwU]

Im not sure this fix is correct. Whether the paramenv has already been canonicalized or not has nothing to do with whether we can encounter consts with aliases as their type.

I would expect the correct fix to be to normalize both types in check_tys_might_be_eq . We probably have to be careful there with errors during normalization because if we're in a probe and have an non wf alias which doesn't cause an error then we don't want to ICE in this check.

Sooo we probably want that fn to call deeply_nornalize then select_all_or_error, but return Ok(()) in case of error. Though at this point this check is becoming a bit of a pain lol...

[ShE3py]

Ty for the pointers, though non-wf aliases ICEs even without deeply_nornalizeing the tys;

struct Sized<T>(T);
type NonWf = Sized<dyn ToString>;

struct Walk<const W: NonWf> {}
impl Walk<{ Sized("") }> {}

https://play.rust-lang.org/?gist=66eb4c5f0a126c73ba8734ef399b639d

@rustbot label -A-testsuite -T-bootstrap

[BoxyUwU]

Why the first commit? You didn't update the function that handles tys and also it shouldn't be required for this as in super_combine_tys we have an infcx available for canonicalization

[ShE3py]

It's for #119381, whose backtrack is as follow:

0. Canonicalizer::fold_const where self.infcx.unwrap() fails
1. InferCtxt::canonicalize_query::{closure#0} where infcx := None
2. CanonicalParamEnvCache::get_or_insert whose docstring says that it shouldn't resolve inference variables as to not invalidates its cache (PR cache param env canonicalization #117749)
3. InferCtxt::canonicalize_query
4. InferCtxt::super_combine_consts
5. InferCtxt::super_combine_tys

Though it may be preferable to (re-)canonicalize ParamEnv (bypassing the cache) in super_combine_consts as to have an infcx?

[bors]

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

[lcnr]

I've avoided to review this PR for a while as this feels very suspicious to me but I wasn't able to explain why without a significant time investment. sorry 😅

The ICE occurs in equate_impl_headers which is used to compute the constraints we can assume. We cannot eagerly replace infer vars with placeholders at this point

rust/compiler/rustc_trait_selection/src/traits/coherence.rs

Line 449 in d86e122

equate_impl_headers(infcx, param_env, &impl1_header, &impl2_header)

We should use an infcx when encountering inference varialbes to make sure these infer vars do not resolve to any other types. I would personally prefer to only do the deeply_normalize change in this PR and fix the negative_coherence issue by cleaning up our const handling in general.

While your approach does work and may at worst slightly worsen type inference here, this change does cause the code to be "conceptionally broken"¹, so I would prefer to not land it, esp given that it's an ICE which only occurs with a nightly feature enabled.

Footnotes

1. this is mostly just vibe based 🤔 using it here as the way to rationalize this change is "yes, this may cause unexpected and wrong results in rare cases, but it's not unsound, so it's fine". It's somewhat difficult to explain exactly what I mean here ↩

[ShE3py]

For context, I tried to add a subdiagnostic “if there's a conflicting implementation and if using negative coherence solves it, suggests adding #![feature(with_negative_coherence)]” but it ICEd some tests, and I may have been too hasty in my attempt to fix it. I’ll try to come up with a nicer approach when I have time.

[lcnr]

@rustbot author

[Dylan-DPC]

@ShE3py any updates on this? thanks

[ShE3py]

Seems like #119381 was fixed by #125451 and no longer ICEs, so I'm closing this.