Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure no type errors when calling Closure/Generator upvars_ty #78392

Closed
wants to merge 1 commit into from

Conversation

arora-aman
Copy link
Member

Fixes #77993

Places with ungaurded calls to upvars_ty would already throw a bug in case of Ty::Error, or we were working with MIR / building MIR exprs.

r? @nikomatsakis

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 26, 2020
Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this looks a little bit different than I expected. I expected to have tupled_upvars_ty just return a Ty (which may be a Ty::Err) and upvar_tys return a Result. That said, having tupled_upvars_ty return a Result seems ok -- but I think that for consistency upvar_tys should also do so, rather than silently ICEing if there is a Ty::Err. It seems like there are a number of calls to upvar_tys that are first guarded by a call to tupled_upvars_ty.is_ok(), which seems like a suboptimal pattern (it would be easy to forget).

@@ -670,7 +673,7 @@ impl<'tcx> UpvarSubsts<'tcx> {
}

#[inline]
pub fn tupled_upvars_ty(self) -> Ty<'tcx> {
pub fn tupled_upvars_ty(self) -> Result<Ty<'tcx>, ErrorReported> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pre-existing to some extent, but I think this function merits a comment. Something like:

Returns a tuple type whose elements are the types of the upvars captured by this closure/generator. Returns Err(ErrorReported) if a type error prevented us from figuring out the types of the upvars for this closure.

@@ -517,13 +519,14 @@ impl<'tcx> GeneratorSubsts<'tcx> {

#[inline]
pub fn upvar_tys(self) -> impl Iterator<Item = Ty<'tcx>> + 'tcx {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I think this function merits a comment too. Something like

Returns an iterator over the upvar types for this closure/generator. This should only be invoked after type check is complete; before that, the upvar types may still be being inferred or may be an inference variable. To access the upvar types before type check is known to have completed, use tupled_upvar_tys.

That said, this will still ICE in the event of a Ty::Err, right? I'm not sure if that's a great idea, as it means that every use of this function has to be guarded by a call to tupled_upvars_ty. Why not make this function return a Result as well (or perhaps an empty vector)?

// Not yet resolved.
Ambiguous

if let Ok(tupled_tys) = substs.as_closure().tupled_upvars_ty() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: it feels like we may want a helper for this pattern of shallow resolving the tupled_upvars_ty, but maybe it doesn't occur that often actually.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see too much benefit here, especially since each case Tuple/Infer/Error will need to be handled at each call site. Also, we only do this in 3 spots.

Fixes rust-lang#77993

Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
@arora-aman
Copy link
Member Author

Closing this in favor of #78432

@arora-aman arora-aman closed this Oct 28, 2020
@arora-aman arora-aman deleted the fix-77993-aman branch October 30, 2020 05:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE: tuple_fields called on non-tuple: async fn with unknown macro
3 participants