RFC 2229 — Roadmap

2019.03.05

  • Current status:
  • PR — cleanup PR landed
  • Problems
  • 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)
  • Make a list of code that uses with_freevars @Nicholas M
  • This executes during MIR construction. We should be able to alter it to use the upvar list.
  • This executes after MIR construction. We should be able to alter it to use the upvar list.
  • This executes after MIR construction. We should be able to alter it to use the upvar list.
  • This executes after type check. We should be able to alter it to use the upvar list.
  • This executes 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 is the code that analyzes how upvars are used. It will eventually become the code that selects which paths to capture. Leave as is for now.
  • This is the code that analyzes how upvars are used. It will eventually become the code that selects which paths to capture. Leave as is for now.
  • Once @blitzerr _ ‘s branch lands, this will go away.
  • 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.
  • This is in the (old and quasi-deprecated) liveness code. It runs after typeck, so we ought to be able to modify it to use the upvar list.
  • This is in the debug printouts. This…is a tricky one, but also not very vital. We can probably just leave it as is for now. 
  • As above.
  • As above.