Don't even try to combine consts with incompatible types

[compiler-errors]

I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a ConstArgHasType predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.

1. Use the type_of for a parameter in try_eval_lit_or_param, instead of the "expected" type from a WithOptConstParam def id.
2. Don't combine consts that have incompatible types.

Fixes #108781

[rustbot]

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

oops forgor to r?

r? @BoxyUwU

[compiler-errors]

The trait ref of impl #1 is S<Const(Param(N/#0): usize)> because of astconv using the type from the L substitution of struct S.

I guess I could be a bit more explicit here -- I'm talking about this code:

rust/compiler/rustc_hir_analysis/src/astconv/mod.rs

Lines 449 to 458 in 39f2657

	(GenericParamDefKind::Const { .. }, GenericArg::Const(ct)) => {
	ty::Const::from_opt_const_arg_anon_const(
	tcx,
	ty::WithOptConstParam {
	did: ct.value.def_id,
	const_param_did: Some(param.def_id),
	},
	)
	.into()
	}

So when instantiating the substs for S<N>, we use the const param did from L, and end up with S<Const(Param(N/#0): usize)>, even though N has the type i32 at its declaration. This is surprising, I guess, but also makes sense from the implementation of the astconv code.

[compiler-errors]

Alternative fix to this would be, uh, replacing this

rust/compiler/rustc_trait_selection/src/traits/specialize/mod.rs

Line 151 in 39f2657

let impl1_trait_ref = tcx.impl_trait_ref(impl1_def_id).unwrap().subst_identity();

with

let impl1_trait_ref = tcx.impl_trait_ref(impl1_def_id).unwrap().subst(tcx, ty::InternalSubsts::identity_for_item(tcx, impl1_def_id));

Or making subst_identity do that in general... Or just delaying a span bug where the original ICE happens. But those both seem like like a spot fix to a bigger problem, where we don't necessarily want/need to do const infer when the consts' types don't match up right due to WF issues.

[BoxyUwU]

r=me if CI passes

[compiler-errors]

@bors r=BoxyUwU

[bors]

📌 Commit f714613 has been approved by BoxyUwU

It is now in the queue for this repository.

[bors]

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.