-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add a map in the TypeckTables to get all Upvars given the a closure ID #56905
Comments
Issue rust-lang#56905 Adding a map to TypeckTables to get the list of all the Upvars given a closureID. This is help us get rid of the recurring pattern in the codebase of iterating over the free vars using with_freevars.
Issue rust-lang#56905 Adding a map to TypeckTables to get the list of all the Upvars given a closureID. This is help us get rid of the recurring pattern in the codebase of iterating over the free vars using with_freevars.
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 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 |
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 (It would have the advantage of mapping the closure more closely to something a user could have written) |
@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 ? |
Issue rust-lang#56905 Adding a map to TypeckTables to get the list of all the Upvars given a closureID. This is help us get rid of the recurring pattern in the codebase of iterating over the free vars using with_freevars.
Rollup of 26 pull requests Successful merges: - #56425 (Redo the docs for Vec::set_len) - #56906 (Issue #56905) - #57042 (Don't call `FieldPlacement::count` when count is too large) - #57175 (Stabilize `let` bindings and destructuring in constants and const fn) - #57192 (Change std::error::Error trait documentation to talk about `source` instead of `cause`) - #57296 (Fixed the link to the ? operator) - #57368 (Use CMAKE_{C,CXX}_COMPILER_LAUNCHER for ccache) - #57400 (Rustdoc: update Source Serif Pro and replace Heuristica italic) - #57417 (rustdoc: use text-based doctest parsing if a macro is wrapping main) - #57433 (Add link destination for `read-ownership`) - #57434 (Remove `CrateNum::Invalid`.) - #57441 (Supporting backtrace for x86_64-fortanix-unknown-sgx.) - #57450 (actually take a slice in this example) - #57459 (Reference tracking issue for inherent associated types in diagnostic) - #57463 (docs: Fix some 'second-edition' links) - #57466 (Remove outdated comment) - #57493 (use structured suggestion when casting a reference) - #57498 (make note of one more normalization that Paths do) - #57499 (note that FromStr does not work for borrowed types) - #57505 (Remove submodule step from README) - #57510 (Add a profiles section to the manifest) - #57511 (Fix undefined behavior) - #57519 (Correct RELEASES.md for 1.32.0) - #57522 (don't unwrap unexpected tokens in `format!`) - #57530 (Fixing a typographical error.) - #57535 (Stabilise irrefutable if-let and while-let patterns) Failed merges: r? @ghost
Related to #53488 |
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.
The text was updated successfully, but these errors were encountered: