interpret: properly check for inhabitedness of nested references#156977
interpret: properly check for inhabitedness of nested references#156977RalfJung wants to merge 1 commit into
Conversation
| ty::Coroutine(..) => { | ||
| true // FIXME should these really be trivially inhabited? | ||
| } | ||
| ty::CoroutineClosure(..) => { | ||
| true // FIXME should these really be trivially inhabited? | ||
| } |
There was a problem hiding this comment.
I wasn't sure how to recurse into these. Are coroutines always inhabited via a trivial start state, or can they be uninhabited due to capturing ! as an "upvar"? How do coroutine closures work?
There was a problem hiding this comment.
Looks like yes they can be uninhabited
Coroutine(DefId(0:13 ~ diverges[9ce3]::async_let::{closure#0}), [(), std::future::ResumeTy, (), !, (Void,)]) is ABI-uninhabited but not opsem-uninhabited?
There was a problem hiding this comment.
I now made them all check the upvar_tys, but I am not entirely sure if that is enough.
| } | ||
| ty::UnsafeBinder(..) => { | ||
| true // FIXME should these really be trivially inhabited? | ||
| } |
There was a problem hiding this comment.
I have no idea what the UnsafeBinder implementation status is but their opsem has not even been discussed yet AFAIK.
| len.try_to_target_usize(tcx).unwrap() == 0 | ||
| || is_opsem_inhabited_recursor(elem, tcx, root, adt_handler) | ||
| } | ||
| ty::Pat(inner, _pat) => is_opsem_inhabited_recursor(inner, tcx, root, adt_handler), |
There was a problem hiding this comment.
I guess in theory the pattern could make a type uninhabited... so technically if we ever want to use that for the opsem we have to add it has a check here before pattern types get stabilized.
| /// | ||
| /// When we git an ADT, we call `adt_handler`, giving it as its last argument a closure that it | ||
| /// can invoke to continue the recursion. | ||
| fn is_opsem_inhabited_recursor<'tcx>( |
There was a problem hiding this comment.
Do we need to do something to bound this recursion? We already stop when encountering the same ADT again, so recursion is bounded by the depth of ADT field types until it comes back to the original type.
Do we need to do some stack growing magic?
This comment has been minimized.
This comment has been minimized.
4e90bd5 to
e6d1440
Compare
This comment has been minimized.
This comment has been minimized.
e6d1440 to
33dc892
Compare
This comment has been minimized.
This comment has been minimized.
33dc892 to
846fa4f
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
This implements the opsem from the ongoing FCP in rust-lang/unsafe-code-guidelines#413. The bit we were previously missing is that transmuting a
&&!into existence was not caught as being immediate UB -- only the&!case behaved as expected.I did not adjust the layout computation because when we compute the layout of
&T, we cannot know the layout ofT(as that might be recursive).r? @oli-obk