Assumptions in the current code that have to be fixed
Number of upvars is baked into the generics of a closure/generator
This is a problem because we have to know the number of generic type parameters and so forth before we actually type-check the closure body
So if the number of captures is going to be dependent on what paths the closure body actually uses(and the types of those paths) then this is a problem
Code that uses the freevars list to determine how many fields/captures/etc a closure has
Steps:
Step 0: Create a suite of test cases that represent the“interesting cases” from the RFC. A list of interesting scenarios:
cases where drop order would change
cases where we access same path x.y via distinct modes(read, write)
cases where we access x.y as read and x.y.z as write
cases where we access x.y as write and x.y.z as read
Step 1: Convert the ClosureSubsts and GeneratorSubsts types to have a fixed number of type parameters, regardless of how many upvars they captured
change the APIs for closure-substs etc to synthesize a tuple type(commit on the branch — because it has perf implications)
change the type check to actually generate a tuple
fix the error messages around trait selection@blitzerr _
Step 2: Change consumers of freevars to not assume one free var per upvar(rust-lang/rust#60205)
A: Add information into the TypeckTables that tracks the upvars(done — upvar list)
Make a list of code that uses with_freevars@Nicholas M
This execintend to write any code, help us add a sectiutes during type-check, which is a problem — however, it is only checking for a special case, when the freevar list is empty, which is something we should be able to continue checking for without a problem. We basically leave this as is.
This executes during and after type check. We should be able to alter it to use the upvar list, but it needs to access the typeck tables through self.mc.tables.
2019.03.05
A: Add information into theTypeckTablesthat tracks the upvars(done— upvar list)