-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Separate unsized fn params from unsized locals #74971
Conversation
@JohnTitor thanks for taking this over because I couldn't check this issue again due to lack of time. This looks good to me but let's see what @RalfJung and @pnkfelix say about it. |
} else { | ||
if !self.fcx.tcx.features().unsized_locals { | ||
self.fcx.require_type_is_sized(var_ty, p.span, traits::VariableType(p.hir_id)); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about fn a(box box b: Box<Box<[u8]>>) {}
? I think that should keep using unsized_locals
and not unsized_fn_params
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I assume that pattern will generate MIR with unsized locals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm yeah, confirmed that it won't work well in this PR. How can we catch such a case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no familiarity with HIR, but it must be possible to somehow check if the function argument is a "trivial" pattern, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no familiarity with HIR, but it must be possible to somehow check if the function argument is a "trivial" pattern, right?
I think p.simple_ident
could be used here as well as https://github.com/rust-lang/rust/pull/74971/files#diff-1d1b0d29a2e8da97c6bfb6e364d920c7R1378-R1381?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe?^^ I'm really the wrong person to ask such questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, anyway thanks for pointing out :) Let's move this topic to Zulip so that the we can get some eyes from other members...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(summarizing my discussion with @spastorino on Zulip)
I think a bigger issue than special-casing the shape of the pattern, is that within_fn_param
applies recursively to every nested pattern in a fn
parameter, instead of to the parameter pattern itself.
So my suggestion is to replace it with a "shallow" version (bikeshed name: outermost_fn_param_pat
) that visit_pat
temporarily sets back to false
around its walk_pat
call, so that the #![feature(unsized_fn_params)]
path is only taken for fn
parameters themselves, not any other patterns nested in them.
The key test for this PR is a file that enables |
☔ The latest upstream changes (presumably #74877) made this pull request unmergeable. Please resolve the merge conflicts. |
@JohnTitor - Can you please address the merge conflict so it can be reviewed? Thank you. |
This still can be reviewed even if it has a merge conflict. I'll resolve it once we come up with a solution for the above point. See also the Zulip topic. |
Which Zulip topic? AFAIK this just needs a check ensuring that the pattern is sufficiently simple. Alternatively, is there a way to check this on the MIR? The pattern has been compiled away there, so that makes it trivial to check if there are just arguments or also locals that are unsized. |
@JohnTitor generally, reviewers are more likely not to review pull requests if it has conflicts |
It sounded to me that this is more waiting on author than waiting on team, @JohnTitor can you confirm that?. |
@spastorino yeah it seemed like the author wanted some help from compiler team, hence marked it as that but after that reading through the conversation, it should be waiting on author :D |
I think zulip topic is this: And there's even more merge conflicts now... |
I'm currently reworking this, I should have a PR up in a few days. |
@Dylan-DPC have rebased this here https://github.com/spastorino/rust/tree/separate-unsized-locals2, please let me know if you're going to continue with this, otherwise I can continue. |
@spastorino since you have the headstart, you can proceed not a problem |
… r=oli-obk Separate unsized locals Closes rust-lang#71694 Takes over again rust-lang#72029 and rust-lang#74971 cc @RalfJung @oli-obk @pnkfelix @eddyb as they've participated in previous reviews of this PR.
Taking over #72029 in favor of #72029 (comment).
Fixes #71694, closes #72029
r? @pnkfelix
cc @RalfJung @spastorino