Skip to content
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

Translate closures through the collector #37675

Merged
merged 4 commits into from
Nov 13, 2016
Merged

Conversation

arielb1
Copy link
Contributor

@arielb1 arielb1 commented Nov 9, 2016

Now that old trans is gone, there is no need for the hack of translating closures when they are instantiated. We can translate them like regular items.

r? @eddyb

impl<'a, 'gcx, 'acx, 'tcx> ClosureSubsts<'tcx> {
#[inline]
pub fn upvar_tys(self, def_id: DefId, tcx: TyCtxt<'a, 'gcx, 'acx>) ->
iter::Map<slice::Iter<'tcx, Kind<'tcx>>, KindAsType>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should just use impl Trait here, maybe you can share the error?
Last I checked most cases can be tricked into inferring correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error[E0564]: only named lifetimes are allowed in `impl Trait`, but `` was found in the type `core::iter::Map<core::slice::Iter<'_, ty::subst::Kind<'tcx>>, [closure@../src/librustc/ty/sty.rs:292:13: 292:66]>`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try + 'tcx on the impl Iterator.

@@ -254,15 +257,38 @@ pub enum TypeVariants<'tcx> {
/// handle). Plus it fixes an ICE. :P
#[derive(Copy, Clone, PartialEq, Eq, Hash, Debug, RustcEncodable, RustcDecodable)]
pub struct ClosureSubsts<'tcx> {
/// Lifetime and type parameters from the enclosing function.
/// Lifetime and type parameters from the enclosing function,
/// concatenated with the types of the upvars.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty much my only concern, that the upvar types are here - in fact, why are they in the type at all?
Why can't they be like ADTs, with the closure pointing to a list of "fields" which are inferred by typeck?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before trans, closure types need the upvars because they contain lifetimes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But couldn't the types with those lifetimes be stored somewhere else, keyed by DefId?
I believe we already do something like that for the signature of the closure.

@eddyb
Copy link
Member

eddyb commented Nov 9, 2016

cc @rust-lang/compiler

@michaelwoerister
Copy link
Member

Nice :)
One thing to note is that after these changes, closures are only instantiated if they are called or there's a vtable for them. Before, we instantiated closures as soon as they were declared. For incremental compilation, the old behavior would provide more stability but in practice this probably won't come up often (or maybe not at all).

@alexcrichton alexcrichton added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 10, 2016
@bors
Copy link
Contributor

bors commented Nov 12, 2016

☔ The latest upstream changes (presumably #37730) made this pull request unmergeable. Please resolve the merge conflicts.

This moves closures to the (DefId, Substs) scheme like all other items,
and saves a word from the size of TyS now that Substs is 2 words.
This makes them closer to actual items and allows for more
transparent treatment.
Translate closures like normal functions, using the trans::collector
interface.
(base_generics.types.len() as u32),
regions: vec![],
types: upvar_decls,
has_self: false,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be base_generics.has_self. Nevertheless, putting generics/type here is a problem.
In #37676 I've added generics for closures in typeck::collect, which is closer to what on-demand type-checking needs.
OTOH your closure_base_def_id is better (or even actually correct) than what I have there, so I'd prefer it.

@eddyb
Copy link
Member

eddyb commented Nov 12, 2016

@arielb1 r=me with the closure generics/type creation moved to typeck::collect as per my comment.

@eddyb
Copy link
Member

eddyb commented Nov 12, 2016

@bors r+

@bors
Copy link
Contributor

bors commented Nov 12, 2016

📌 Commit d394e75 has been approved by eddyb

@bors
Copy link
Contributor

bors commented Nov 12, 2016

⌛ Testing commit d394e75 with merge a277f9d...

bors added a commit that referenced this pull request Nov 12, 2016
Translate closures through the collector

Now that old trans is gone, there is no need for the hack of translating closures when they are instantiated. We can translate them like regular items.

r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants