Add consts for AssocConst w/ body & ignore regions in is_satisfied_from_param_env

[JulianKnodt]

Add in the ability to unify associated consts and ignore regions when unifying consts.
Attempting to only ignore regions lead to an ice, so I had to add that the associated const would be unified with it.

Handles one of the minimized test cases in #105821, but not sure if it fixes everything.

Fixes #106423 (but I think it may break the compilation of some crates, as I'm not sure if we were previously permitting that behavior?)

r? @BoxyUwU

[rustbot]

Some changes occurred in const_evaluatable.rs

cc @BoxyUwU

Some changes occured in rustc_ty_utils::consts.rs

cc @BoxyUwU

[BoxyUwU]

I don't think these changes actually fix the problem. There's no infer var in the linked issue, we're just unable to evaluate a ConstKind::Expr. The reason it no longer ICEs with these changes is because you emitted an error which is stopping us from getting to monomorphization which is where the ICE happens.

[JulianKnodt]

Yes, but I'm not sure whether this was ever intended for this to compile or not. I went back through a few nightly builds over the past 2 years, and it seems it's intermixed with ICE-ing, compiling, and not compiling. Do we intend to handle AssocConsts as Exprs? If we treat them as Exprs, then since we cannot handle all operations it makes sense that this shouldn't compile. If we do want it to compile, then this should not be what is merged in at the end.

[BoxyUwU]

I am not sure what you mean by treating an assoc const as an Expr. I would expect <T as Trait>::ASSOC to be a ConstKind::Unevaluated that can potentially be normalized to a ConstKind::Expr if the actual value in the impl would be valid (i.e. not hit the errors in thir_abstract_const)

[JulianKnodt]

Right, but I was wondering whether we should always treat AssocConsts as Exprs? What I suspect is that we were previously trying to convert them into AbstractConsts (prior to the addition of Expr), and ignoring them because it was not supported. Do AssocConsts support arbitrary expressions, and if so what defines if we try to convert it into an Expr?

Overall, I think I'm just not sure what the intended output behavior is. Should this compile at all?

[bors]

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

[pnkfelix]

I think this is best owned by T-types rater than T-compiler

@rustbot label: +T-types -T-compiler

[KittyBorgX]

@rustbot author
@JulianKnodt Hello! There are some merge conflicts, can you resolve them?
The reviewers can then leave a review and your PR should be good to go.

Once you sort the conflicts, type in @rustbot review here to change the label to S-waiting-on-review

[JulianKnodt]

I'm probably just going to close this, as I think how I thought this should be resolved is different from what the maintainers expected, and I don't really know how to proceed further. Thanks for the reminder!