Add a map in the TypeckTables to get all Upvars given the a closure ID

[blitzerr]

It is a recurring pattern in the rustc compiler base to iterate thorough all the free-variables (or Upvars as they are also known as) using with_freevars. It might be better to have a list of all the Upvars given a closure id.

[nikomatsakis]

Leaving some notes here:

It's clear that we want to remove the use of freevars wherever possible, since all that code is basically assuming that the set of captures for a closure is equal to the set of variables referenced from within that closure.

In most of these cases, it should be fairly straightforward: typeck can instead produce a list of captures and the code can use that list.

However, there are a few cases that are going to be more complex. The most notable is the place where we determine the "generics" (set of generic parameters) for a closure type. The problem is that, currently, the set of generic parameters include one generic parameter for each free variable.

I'm not really sure how best to fix this. I suppose the ideal would be if we could avoid generating TyClosure types until the initial type check is done. This may be plausible.

Hmm, perhaps an alternative could be to make the "upvar types" always be a tuple of the actual upvar types, with the arity not known until after type-check is done. During type-check, this would just be an inference variable (just as, today, all the types of the upvars are inference variables). After upvar inference, we would unify that variable with a tuple with the types of each upvar (just as, today, we unify each of the individual upvar variables with its final type).

A quick inspection of the users of upvar_tys suggests that this could work. We could do this refactoring today.

[nikomatsakis]

I suppose we could even, but we probably don't want to, make closures always store their upvars in a tuple, so that we access field #x as closure.upvars.x instead of closure.#x. Hmm. This might turn out more convenient, though it would also complicate some of the code in the borrow-checker which would now have to work harder to figure out if a given field reference is an "upvar field" reference.

(It would have the advantage of mapping the closure more closely to something a user could have written)

[blitzerr]

@nikomatsakis Can we close this issue as we can treat this as a logical wrapup. For the tuple introduction, I created another issue with the next steps ?