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

Separate unsized fn params from unsized locals #74971

Closed
wants to merge 8 commits into from

Conversation

JohnTitor
Copy link
Member

@JohnTitor JohnTitor commented Jul 31, 2020

Taking over #72029 in favor of #72029 (comment).
Fixes #71694, closes #72029

r? @pnkfelix
cc @RalfJung @spastorino

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 31, 2020
@spastorino
Copy link
Member

@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));
}
}
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

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

The params should all have a pat that's immediately Binding.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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...

Copy link
Member

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.

@RalfJung
Copy link
Member

RalfJung commented Aug 5, 2020

The key test for this PR is a file that enables unsized_fn_params but not unsized_locals, and then checks that all uses of unsizd locals except for fn params error. I can't see this PR add such a test, but maybe I missed it in the various test suite changes?

@bors
Copy link
Contributor

bors commented Aug 8, 2020

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

@JohnCSimon JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 25, 2020
@JohnCSimon
Copy link
Member

@JohnTitor - Can you please address the merge conflict so it can be reviewed? Thank you.

@JohnTitor
Copy link
Member Author

JohnTitor commented Aug 25, 2020

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.

@JohnTitor JohnTitor added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 25, 2020
@RalfJung
Copy link
Member

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.

@Dylan-DPC-zz Dylan-DPC-zz added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 25, 2020
@Dylan-DPC-zz
Copy link

@JohnTitor generally, reviewers are more likely not to review pull requests if it has conflicts

@spastorino spastorino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Aug 26, 2020
@spastorino
Copy link
Member

It sounded to me that this is more waiting on author than waiting on team, @JohnTitor can you confirm that?.

@Dylan-DPC-zz
Copy link

@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

@Dylan-DPC-zz Dylan-DPC-zz removed the S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). label Aug 27, 2020
@Dylan-DPC-zz Dylan-DPC-zz added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 27, 2020
@crlf0710
Copy link
Member

@Dylan-DPC-zz
Copy link

I'm currently reworking this, I should have a PR up in a few days.

@spastorino
Copy link
Member

spastorino commented Sep 24, 2020

@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.

@Dylan-DPC-zz
Copy link

@spastorino since you have the headstart, you can proceed not a problem

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Oct 28, 2020
… 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.
@JohnTitor JohnTitor deleted the separate-unsized-locals branch June 7, 2021 05:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

Separate unsized_locals into "sound" and "unsound" (i.e. incorrectly implemented) parts