MIR-borrowck: immutable unique closure upvars can be mutated

[davidtwco]

Fixes#46023 and #46160 (see this comment).

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[davidtwco]

This isn't quite working yet and I'm not quite sure why. I think I've followed the instructions left on the issue correctly.

r? @nikomatsakis@arielb1

[arielb1]

nit: rename it to pub capture_mode: Option<BorrowKind>?

[arielb1]

nit: if let Some(BorrowKind::Unique) = decl.by_ref {

[arielb1]

I think you also need to change check_if_reassignment_to_immutable_state to use the new is_mutable logic - it handles error reporting for unique-immutable assignments. Otherwise assignments will not quite work. I think that's why the test is broken.

[davidtwco]

Pushed an alternate approach after speaking with @arielb1on Gitter - it isn't working yet but I think I've implemented the mutability field in UpvarDecl as per our conversation.

[arielb1]

You still need the move_path_closest_to change here. Also, for assignments you want to move_path_closest_to the original lvalue, not the result of is_mutable, in order to allow

fnmain(){let x:(u32,u32);
x.0 = 0;
x.1 = 1;}

[arielb1]

@davidtwco

BTW, if you're already at this, you could also fix #46160 by marking the closure argument (argument _1 of a closure) as mutable

[davidtwco]

I've not done much testing of what I just pushed, but I've added work from all the instruction provided over the past few days. It includes a rebase onto current master which included #46022 which @arielb1 said I might need.

[bors]

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

[davidtwco]

Pushed a compiling version of the last changes and rebased ontop of the current master. Wasn't sure what to use for the new parameter to is_mutable.

[arielb1]

@bors r+

[bors]

📌 Commit c6b1ba5 has been approved by arielb1

[bors]

⌛ Testing commit c6b1ba5 with merge e3ed212...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing e3ed212 to master...

[eddyb]

This should have been merged like this, UpvarDecl was "supposed" to be debuginfo-only 😞.
But I'm not sure where to put this information - presumably it belongs attached to the closure type.

[nikomatsakis]

@eddyb

But I'm not sure where to put this information - presumably it belongs attached to the closure type

Hmm. Maybe, but I'm not sure. I guess it depends on how you view the mut information. I don't think of it as part of the type system, but rather a kind of lint that sits on top. But I suppose we do issue hard errors and so forth, so it's reasonable to view it as information that belongs in the closure type. It's sort of nice though that the "closure subst" is just types right now, and I'm not sure I want to change that. Another option would be to add some closure_upvar_info query that takes a closure def-id and gives further information, though — sort of like the existing free_vars calculation?

(On the other hand, maybe it's nice to have all the upvar information collected in one place...)

( <grumpy> I still think we should just drop the notion of declaring local variables as mut altogether. =) </grumpy> )