You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These substs don't behave like ordinary generic parameters, negatively impact perf and are difficult to understand or deal with in some cases.
We should try to remove these synthetic parameters, for example by moving them into TypeckResults and treating closures a lot more similar to ordinary adts. The same approach should also be used for generators and inline consts.
How can this soundly interact with inference? IIRC, the reason they're like this today, is so that parts of that information can be left as inference variables, in a way that interfaces with everything that handles inference variables (that is, I remember them being stored in an ad-hoc way in InferCtxt and that having issues).
The only thing I can think of, that would work with e.g. canonicalization, would be to put the information in ParamEnv, something like a foo::{closure#0}: FnOnce<$123> bound - but are inference variables in ParamEnv supported?
Also, regarding upvars, ADTs differ a lot from tuples, in how their fields interact with various aspects of traits and lifetimes, and tuples are much more straight-forward IMO - you would have to look for every place in the compiler where either ty::Adt or ty::Tuple are handled, and consider the implications of switching closures from one approach to the other.
But still, it would have to be in something like ParamEnv, instead of always being able to do a query for "field types" the way ADTs can, otherwise how can you reason about e.g. foo::{closure#0}: Sync during inference?
(Also, I am not aware of any precedent where some trait system interaction with a type can involve inference variables that are not in the type itself - anything that relies on type flags may be broken).
right now, we add synthetic generic parameters to closures to represent a bunch of additional information about the closure, see
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/sty/struct.ClosureSubsts.html
These substs don't behave like ordinary generic parameters, negatively impact perf and are difficult to understand or deal with in some cases.
We should try to remove these synthetic parameters, for example by moving them into
TypeckResults
and treating closures a lot more similar to ordinary adts. The same approach should also be used for generators and inline consts.Going to look into this myself for now
cc @nikomatsakis
The text was updated successfully, but these errors were encountered: