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

NLL diagnostics miss opportunities to suggest "change this to mut" #51031

Closed
8 tasks
pnkfelix opened this issue May 24, 2018 · 5 comments
Closed
8 tasks

NLL diagnostics miss opportunities to suggest "change this to mut" #51031

pnkfelix opened this issue May 24, 2018 · 5 comments
Labels
A-NLL Area: Non-lexical lifetimes (NLL) E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. NLL-diagnostics Working towards the "diagnostic parity" goal

Comments

@pnkfelix
Copy link
Member

pnkfelix commented May 24, 2018

The following tests rightly suggest under AST borrowck to consider adding mut to the binding site, but there is no such suggestion under NLL.

Tests:

  • augmented-assignments.rs
  • codemap_tests/huge_multispan_highlight.rs
  • did_you_mean/issue-31424.rs
  • did_you_mean/issue-39544.rs
  • macros/span-covering-argument-1.rs
  • span/borrowck-borrow-overloaded-auto-deref-mut.rs
  • span/borrowck-borrow-overloaded-deref-mut.rs
  • span/borrowck-object-mutability.rs

(This list of tests is drawn from an informal paper document that I have been using to keep notes for myself as I work on this...)

@pnkfelix pnkfelix added A-NLL Area: Non-lexical lifetimes (NLL) WG-compiler-nll NLL-diagnostics Working towards the "diagnostic parity" goal labels May 24, 2018
@nikomatsakis
Copy link
Contributor

Here are some tips on where this might need to get fixed. For things like X = ..., where a variable is being directly assigned, I think we wind up in this path of the code:

fn check_if_reassignment_to_immutable_state(
&mut self,
context: Context,
(place, span): (&Place<'tcx>, Span),
flow_state: &Flows<'cx, 'gcx, 'tcx>,
) {

Notably, this call to is_mutable — when it returns Err — also returns some information about why this path is not mutable:

) -> Result<RootPlace<'d, 'tcx>, &'d Place<'tcx>> {

(You can see that is_mutable returns a Place in the event of error here.)

I think that in the case we want, the "not mutable cause" will be a Place::Local; we could thread that Local through to the following function to use for making suggestions:

self.report_illegal_reassignment(context, (place, span), init.span);

(Given a mir::Local, we have to ask the Mir for the LocalDecl, which will tell us if this is a user_variable and also where it was declared etc for use when making the suggestion.)

@nikomatsakis nikomatsakis added the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label May 29, 2018
@nikomatsakis
Copy link
Contributor

If you'd like to help out with this, come join the NLL working group on Zulip.

@spastorino spastorino self-assigned this May 29, 2018
@nikomatsakis
Copy link
Contributor

It turns out that we have this code already:

err.note(&format!("the value which is causing this path not to be \
mutable is...: `{}`", name));

I think we ought to be replacing that code with a better version. After all, that code doesn't look like it gives particularly useful errors today:

error[E0594]: cannot assign to immutable item `x`
  --> $DIR/issue-45983.rs:17:18
   |
LL |     give_any(|y| x = Some(y));
   |                  ^^^^^^^^^^^ cannot mutate
   |
   = note: the value which is causing this path not to be mutable is...: `x`

What we would need to do:

  • Remove the if place != place_err; instead, test if place_err matches Place::Local(l)
  • If so, find the local declaration for l (self.mir.local_decls[l])
    • if is_user_variable is true, continue
    • mutability should be immutable
    • the source_info can give you the span
  • Construct a suggestion based on this

@pnkfelix
Copy link
Member Author

I think the same code that is doing this check (fn check_access_permissions) will also end up being responsible for properly checking #51032. So it might be good to combine some effort there, and/or think about both issues when looking at replacing this code with a better version.

(I do agree that the code here needs revision.)

@pnkfelix
Copy link
Member Author

pnkfelix commented Jun 4, 2018

I believe this will be eventually addressed by PR #51275 once that is finalized.

bors added a commit that referenced this issue Jun 19, 2018
…ermissions, r=nikomatsakis

NLL diagnostics: revise `fn check_access_permissions`

NLL: revise `fn check_access_permissions` so that its (still branchy) shares more code paths between the different cases, and also provide more diagnostics in more cases (though the added diagnostics still do not always meet the quality bar established by AST-borrowck)

----

Transcribing "checklist" suggested by Niko, except I am rendering it as a table to make it clear that I do not regard every item in the list to be a "must have" for landing this PR.

goal | does this PR do it?
-----|------------------------------
no suggestions for `ref mut` |  yes
suggestions for direct local assignment (`{ let x = 3; x = 4; }`) | yes (see commits at end)
suggestions for direct field assignment (`{ let x = (3, 4); x.0 = 5; }` | yes (see commits at end)
suggestions for upvars (`let x = 3; let c = \|\| { &mut x; }`) | yes

Note that I added support for a couple of rows via changes that are not strictly part of `fn check_access_permissions`. If desired I can remove those commits from this PR and leave them for a later PR.

Fix #51031
Fix #51032
(bug #51191 needs a little more investigation before closing.)
Fix #51578
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NLL Area: Non-lexical lifetimes (NLL) E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. NLL-diagnostics Working towards the "diagnostic parity" goal
Projects
None yet
Development

No branches or pull requests

3 participants