Clarify why InhabitedPredicate::instantiate_opt exists by meithecatte · Pull Request #137820 · rust-lang/rust (original) (raw)

Hm, actually, why is that the case? I've played around with it a little and couldn't make it blow up, but I'd like to understand what's going on here.

My understanding from looking at the users of instantiate is that its only really used when creating InhabitedPredicate corresponding to fields of ADTs that we have some generic arguments for. E.g.

struct Foo { field: T }

given some Foo<u8> we'd want to check if u8 is inhabited, not some unknown type T. Afaict this happens by creating an InhabitedPredicate::GenericType(T) and instantiate T=u8.

So then the question becomes if you can write a field of a struct whose type is an opaque type (i.e. an impl Trait) so that when we make a InhabitedPredicate::OpaqueType(Opaque<T>) and then instantiate it we dont wind up instantiating T=u8.

I don't think this is possible as we don't support just writing field: impl Trait and using type_alias_impl_trait like:

type Foo = impl Sized; struct Bar { field: Foo }

Actually desugars to something like:

opaque type Opaque: Sized; type Foo = Opaque; struct Bar { field: Foo }

Where the type of field isnt directly an opaque, but some type alias which is represented by InhabitedPredicate::GenericType(Foo<T>) which does handle instantiate correctly, resulting in an InhabitedPredicate::GenericType(Foo<u8>) which will later be converted to InhabitedPredicate::OpaqueType(Opaque<u8>) (note the correct generic arguments).

It's possible there is actually a way to get this codepath to be triggered but if it is then we should be handling it correctly instead of returning None. But I can't figure out a test case for it and wouldn't want to try and fix it "ahead of time" without a regression test. ICEing is a great way to get people to give you a test case 😅