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

Fix monomorphization of unboxed closures #18144

Conversation

bkoropoff
Copy link
Contributor

This allows unboxed closures that reference free type/region parameters to be monomorphized correctly in trans.

It was necessary to make ty_unboxed_closure carry around a Substs to accomplish this. Plumbing this through typeck revealed several areas where type/region parameters in unboxed closure types are possibly not being handled correctly. Since my goal was just to fix trans, I decided to leave FIXME comments on areas that still need attention and seek feedback on the best way to clean them up, possibly as a follow-up PR.

Closes #16791

@alexcrichton
Copy link
Member

r? @pcwalton

@pcwalton
Copy link
Contributor

Looks fine to me but I should punt this over to @nikomatsakis. Does this look good to you?

@bkoropoff
Copy link
Contributor Author

Rebased

@nikomatsakis
Copy link
Contributor

Sorry for delay. Was out last week. Will look at it ASAP.

@nikomatsakis
Copy link
Contributor

This is cool. At first when I read the patch I thought this was the wrong approach, and that it made more sense to just apply the current monomorphization substitutions in scope during trans. But of course that doesn't work when you are invoking other functions where a type parameter is unbound to an unbound function type, nor will it work in future with things like -> impl Trait and so forth. Nice.

One thing I would like to see is a comment explaining how substitutions in unboxed closures work. I am not sure of the best place, but the def'n of the variant ty_unboxed_closure (in the enum sty) wouldn't be terrible. I'd like to see a description saying roughly the following things:

  • The generics parameters in scope for an unboxed closure type are the same as the enclosing fn.
  • The set of substitutions begins as the free_substs from the parameter environment and changes over time.

@nikomatsakis
Copy link
Contributor

r+ modulo nits.

@carllerche
Copy link
Member

I am unsure if I found a related or unrelated issue, but I applied this PR to work around the issue that it is fixing and then hit another ICE.

See issue #18378

This adds a `Substs` field to `ty_unboxed_closure` and plumbs basic
handling of it throughout the compiler. trans now correctly
monomorphizes captured free variables and llvm function defs.  This
fixes uses of unboxed closures which reference a free type or region
parameter from their environment in either their signature or free
variables.  Closes rust-lang#16791
@bkoropoff bkoropoff force-pushed the mighty-monomorphizin-unboxed-closures branch from e16c8b7 to e46af8c Compare October 28, 2014 01:52
@bkoropoff
Copy link
Contributor Author

Fixed nits and rebased on latest master due to merge conflict. I'm still running tests locally, but this should be ready for r+.

bors added a commit that referenced this pull request Oct 28, 2014
…osures, r=nikomatsakis

This allows unboxed closures that reference free type/region parameters to be monomorphized correctly in trans.

It was necessary to make `ty_unboxed_closure` carry around a `Substs` to accomplish this.  Plumbing this through typeck revealed several areas where type/region parameters in unboxed closure types are possibly not being handled correctly.  Since my goal was just to fix trans, I decided to leave FIXME comments on areas that still need attention and seek feedback on the best way to clean them up, possibly as a follow-up PR.

Closes #16791
@bors bors closed this Oct 28, 2014
lnicola pushed a commit to lnicola/rust that referenced this pull request Sep 25, 2024
fix: Remove check that text of `parse_expr_from_str()` matches the produced parsed tree

This check is incorrect when we have comments and whitespace in the text.

We can strip comments, but then we still have whitespace, which we cannot strip without changing meaning for the parser. So instead I opt to remove the check, and wrap the expression in parentheses (asserting what produced is a parenthesized expression) to strengthen verification.

Fixes rust-lang#18144.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Internal compiler error related to sizing of unboxes closures
7 participants