Make type_of for RPITITs GAT on traits return a ty::Error if no default provided

[spastorino]

Fixes #113434

This one is interesting because it ICEs on both master and in the new RPITIT impl.

I think the code is self-explanatory but we want to avoid delaying a bug and calling opaque::find_opaque_ty_constraints_for_rpit(tcx, def_id, owner) when we already know we can't build a type.

r? @compiler-errors

[compiler-errors]

Why exactly do we even try to call type_of on the RPITIT in the first place?

[spastorino]

Why exactly do we even try to call type_of on the RPITIT in the first place?

Something interesting is that ...

#![feature(return_position_impl_trait_in_trait)]

struct Wrapper<G: Send>();

trait Foo {
    fn bar() -> Wrapper<impl Send>;
}

fn main() {}

This example doesn't ICE, so I guess doesn't call type_of

[spastorino]

Why exactly do we even try to call type_of on the RPITIT in the first place?

So from what I see we're trying to check Foo::bar is WF.

This is the process we follow with the RPITIT def_id

check_associated_item
assumed_wf_types_and_report_errors
iterates over assumed_wf_types results and calls deeply_normalize
select_where_possible
select
process_obligations
process_trait_obligation
poly_select
confirm_candidate
confirm_auto_impl_candidate
constituent_types_for_ty
type_of

This process seems reasonable to me but I'm not sure if we should change something and what exactly. So we select an auto impl candidate because of impl Sized, then need to call constituent_types_for_ty which calls type_of for opaques. Unless we want to do something special here https://github.com/spastorino/rust/blob/ca94899db9ec4fe27bcda746bfda537402aff666/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2352 I'm not sure what to do exactly.

[spastorino]

Another interesting thing is that this example:

#![feature(return_position_impl_trait_in_trait)]

struct Wrapper<G: Sized>(G);

trait Foo {
    fn bar() -> Wrapper<impl Send>;
}

fn main() {}

Doesn't produce any issue. We need the impl trait to be an impl auto trait in return position in order to reproduce this.

[compiler-errors]

I don't think that's enough of an explanation for why this is happening. All you've provided is the call stack of the ICE and a couple of examples that don't ICE 😅

doesn't explain why we're registering this obligation and why we're actually getting the opaque that has no hidden type.

This at least needs a bit more of an explanation so I can be convinced there's some better place to put this fix, without having to actually investigate it myself...

@rustbot author

[spastorino]

Closing in favor of #113741