Don't suggest &mut mut

[saleemjaffer]

fixes #57431

[rust-highfive]

r? @varkor

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

[saleemjaffer]

r? @spastorino

[saleemjaffer]

@spastorino I have added a coerced field in BindByValue. Things only compile now. What do you think?

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:24cb5920:start=1554786460307083927,finish=1554786536254755371,duration=75947671444
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[spastorino]

Yeah, continue in this direction. I'm not entirely sure if adding the attribute there is the best idea as we discussed on Zulip. Anyway, keep this going, now you need to assign coerced to true in the right spot and handle that in the diagnostics part :).

[matthewjasper]

Looking at the way this message is generated, I think that a larger change is probably deserved here.
If you just want to avoid the incorrect message though. I would suggest moving the flag to mir::Ravlue::Ref or mir::BorrowKind. You can then retrieve the flag by inspecting mir.basic_blocks()[locations[0].block].statements.get(locations[0].statement_index) here:

rust/src/librustc_mir/borrow_check/mutability_errors.rs

Line 572 in 316a391

let assignment_rhs_span = mir.source_info(locations[0]).span;

[saleemjaffer]

@matthewjasper This is the the output of mir.basic_blocks()[locations[0].block].statements.get(locations[0].statement_index):
Some( _3 = &(*_5),).

I have no idea how to make sense of what this means. Any help?

[matthewjasper]

The Debug implementation for Statement pretty prints the statement. That's the output for something like

Statement {
    source_info: / * ... */,
    kind: StatementKind::Assign(
        _3,
        Rvalue::Ref('_, BorrowKind::Shared, *_5),
    ),
}

[saleemjaffer]

@matthewjasper

I tried: println!("{:#?}", mir.basic_blocks()[locations[0].block].statements.get(locations[0].statement_index));

Should I be doing something else?

Looks like we cannot pretty print this! Can we?

[bors]

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

[matthewjasper]

There's no way to structurally pretty print. You can match on the some case and print out the .kind, which has a derived Debug implementation (but it's fields all have hand written debug implementations). You can have a look at https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.StatementKind.html to see how this type looks.

[matthewjasper]

Alternatively you could look in mir/mod.rs and replace the manual debug implemenations with derived ones while you're working (and revert later).

rust/src/librustc/mir/mod.rs

Line 1868 in d4a32d5

impl<'tcx> Debug for Statement<'tcx> {

rust/src/librustc/mir/mod.rs

Line 2159 in d4a32d5

impl<'tcx> Debug for Place<'tcx> {

rust/src/librustc/mir/mod.rs

Line 2302 in d4a32d5

impl<'tcx> Debug for Operand<'tcx> {

rust/src/librustc/mir/mod.rs

Line 2475 in d4a32d5

impl<'tcx> Debug for Rvalue<'tcx> {

[spastorino]

r? @varkor, assigning you again because I don't have rights to merge. Anyway this is not ready :).

[varkor]

Suggested change

	ty::BindByValue{..} => {
	ty::BindByValue { .. } => {

(here and elsewhere)

[jonas-schievink]

Ping from triage @saleemjaffer, there's merge conflicts waiting to be resolved

[pnkfelix]

I'm going to close this PR since it seems to be inactive and incomplete. (If nothing else, it lacks a regression test.)

as @matthewjasper said, we probably should try to resolve the problem of #57431 via a larger change.