ICE: `unexpected infer type` about rust HOT 4 OPEN

Regression in nightly-2023-02-18

looking for regression commit between 2023-02-17 and 2023-02-18
fetching (via remote github) commits from max(9a7cc6c, 2023-02-15) to 9aa5c24
ending github query because we found starting sha: 9a7cc6c
get_commits_between returning commits, len: 8
commit[0] 2023-02-16: Auto merge of #108127 - matthiaskrgr:rollup-kpzfc6j, r=matthiaskrgr
commit[1] 2023-02-16: Auto merge of #107833 - Zoxc:arena-query-clean, r=cjgillot
commit[2] 2023-02-17: Auto merge of #108145 - matthiaskrgr:rollup-bgadak1, r=matthiaskrgr
commit[3] 2023-02-17: Auto merge of #107753 - kylematsuda:type-of, r=BoxyUwU
commit[4] 2023-02-17: Auto merge of #108058 - Zoxc:query-ctxtx-byval, r=cjgillot
commit[5] 2023-02-17: Auto merge of #107965 - BoxyUwU:add_const_arg_has_type_predicate, r=compiler-errors
commit[6] 2023-02-17: Auto merge of #108159 - matthiaskrgr:rollup-5k2j7cx, r=matthiaskrgr
commit[7] 2023-02-17: Auto merge of #108075 - WaffleLapkin:de-arena-allocates-you-OwO, r=Nilstrieb
ERROR: no CI builds available between 9a7cc6c and 9aa5c24 within last 167 days

from rust.

Oh, I see. I forgot about tcx.types.trait_object_dummy_self (FreshTy(0)) in #121258. Ofc, my PR doesn't regress anything here but still I forgot about this case. Very likely we need to reject trait_object_dummy_self manually and can't rely on registering a <Ty as core::marker::ConstParamTy> obligation¹ (which I plan to do to fix #119783 but the location is still unclear to me²) because we just shouldn't be feeding the fake FreshTy(0) to type_of as can be seen by the ICE, the trait solver & the inference engine obviously can't handle such malformed obligations.

from rust.

Wait, I don't think we should deny trait_object_dummy_self in the code path that rejects early-bound and escaping late-bound vars, that's not the right thing to do. They are semi-legitimate types that get discarded by helpers like ExistentialTraitRef::erase_self_ty and ExistentialProjection::erase_self_ty, e.g. inside lower_trait_object_ty (which also introduces these dummy_self types).

Oh, okay, so inside lower_trait_object_ty we discard const projections if their args contain a dummy self type but in our case, the projected type (the type_of(proj)) contains a dummy self type.

As the comment over there says such a (const) projection would expand to an infinitely-long type. We also need to check the projected type for dummy self types and drop the existential const projection in case we find any. Edit: Tho, no I'm confused since the projection_ty and the term.ct().ty() should be same in this case due to the anon const feeding, so why isn't it detecting anything? 🤔 Update: We don't even reach the aforementioned branch inside lower_trait_object_ty for some reason. Update: Oh, that's not the code path we're interested in, that's only for super trait elab.

from rust.

Stopping my investigations for now but overwriting the args (incl. the self type subst) of such projections with {type error} as well turning the const projection term into {const error} if the args or the type of the projected const contains trait_object_dummy_self didn't help. Note that lower_trait_object_ty does parts of this already.

I haven't dug deeper yet but the cause of this might be the anon const query feeding in lower_assoc_item_binding: We may feed trait_object_dummy_self to type_of(AnonConst) which can't be undone.

from rust.