Don't inspect the generated existential type items #51773
Conversation
rust-highfive
added
the
S-waiting-on-review
| @@ -419,7 +419,7 @@ fn convert_item<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, item_id: ast::NodeId) { | |||
| convert_variant_ctor(tcx, struct_def.id()); | |||
| } | |||
| }, | |||
| hir::ItemExistential(..) | | |||
| hir::ItemExistential(..) => {} | |||
There was a problem hiding this comment.
Is this always something we will want to skip...? or will we want to do something here when user-given predicates are permitted?
Actually I think in general that we've been wanting to get rid of this part of the code anyway, which maybe isn't strictly needed anymore? (Though it may be good for generating the errors in a predictable order)
There was a problem hiding this comment.
We will want this even before user defined existentials. It's just that right now these existential types can't really live on their own because their generics still refer to generics of their parent function. Once we get that fully separated, there won't be any more code running twice with different settings on this node
| let def = self.map.defs.get(&lifetime.id).cloned(); | ||
| if let Some(Region::LateBound(_, def_id, _)) = def { | ||
| let def = self.map.defs.get(&lifetime.id); | ||
| if let Some(&Region::LateBound(_, def_id, _)) = def { |
There was a problem hiding this comment.
It still seems like it might be good not to generate the late-bound entries we do, as they are pretty malformed, and can lead to ICEs and confusion down the line.
There was a problem hiding this comment.
I'll reinstate your removal code
oli-obk
force-pushed
the
cleanup_impl_trait
branch
from
00b7c75 to
a6bcb9d
Compare
|
☔ The latest upstream changes (presumably #51805) made this pull request unmergeable. Please resolve the merge conflicts. |
oli-obk
force-pushed
the
cleanup_impl_trait
branch
from
a6bcb9d to
28a76a9
Compare
|
@bors r+ |
|
📌 Commit 28a76a9 has been approved by |
bors
added
S-waiting-on-bors
Don't inspect the generated existential type items r? @nikomatsakis My debugging led me to the `hir::ItemExistential(..)` checks, which are entirely unnecessary because we never use the items directly. The issue was that items were iterated over in a random order (due to hashmaps), so if you checked the `ItemExistential` before the function that has the actual return `impl Trait`, you'd run into those ICEs you encountered.
|
☀️ Test successful - status-appveyor, status-travis |
r? @nikomatsakis
My debugging led me to the
hir::ItemExistential(..)checks, which are entirely unnecessary because we never use the items directly. The issue was that items were iterated over in a random order (due to hashmaps), so if you checked theItemExistentialbefore the function that has the actual returnimpl Trait, you'd run into those ICEs you encountered.