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: Deduplicate errors for incorrect move in loop #53995

Merged
merged 3 commits into from Sep 19, 2018

Conversation

Projects
None yet
7 participants
@davidtwco
Member

davidtwco commented Sep 6, 2018

Fixes #53807.

r? @nikomatsakis

@davidtwco

I'm not sure if this approach to deduplicating errors is the best approach, but it seems to have been relatively effective with only one case I'd consider a regression.

I'm happy to take another approach if this isn't deemed optimal.

@memoryruins memoryruins added the A-NLL label Sep 6, 2018

@nikomatsakis

This comment was marked as outdated.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Sep 6, 2018

Contributor

@bors r+

Contributor

nikomatsakis commented Sep 6, 2018

@bors r+

@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 6, 2018

Contributor

📌 Commit b45648b has been approved by nikomatsakis

Contributor

bors commented Sep 6, 2018

📌 Commit b45648b has been approved by nikomatsakis

@@ -1,23 +1,3 @@
error[E0382]: use of moved value: `foo`

This comment has been minimized.

@pnkfelix

pnkfelix Sep 6, 2018

Member

Hmm. Do you have an intuition as to which of the errors are being preferred for presentation by this PR? I am a little surprised to see it favoring the error on line 29 here over the ones on line 28.

I guess I'd want to make sure we don't run into a scenario where a beginner erroneously infers that some statement is not performing a move (or does not have a use of the local, whatever), when in fact there is a move/use at that statement, but the diagnostic system is filtering the error mentioning it out from the error report.

@pnkfelix

pnkfelix Sep 6, 2018

Member

Hmm. Do you have an intuition as to which of the errors are being preferred for presentation by this PR? I am a little surprised to see it favoring the error on line 29 here over the ones on line 28.

I guess I'd want to make sure we don't run into a scenario where a beginner erroneously infers that some statement is not performing a move (or does not have a use of the local, whatever), when in fact there is a move/use at that statement, but the diagnostic system is filtering the error mentioning it out from the error report.

This comment has been minimized.

@davidtwco

davidtwco Sep 6, 2018

Member

This PR groups errors by the MoveOutIndex(s) that are relevant (however this error reporting function was coming to that conclusion previously) and then emitting, for that grouping, the error that corresponds to the place that is most "specific".

In this case, a more "specific" means a Place that is not a prefix of a less "specific" Place. So I just decline to create and buffer an error if the Place for that error is a prefix of the Place that I already have a buffered error for.

There's a log statement that indicates an error is being suppressed and you still get the log statement showing which arguments the reporting function was called with before it suppresses it. There's also a comment attempting to explain the above logic on the field that stores the buffered errors.

@davidtwco

davidtwco Sep 6, 2018

Member

This PR groups errors by the MoveOutIndex(s) that are relevant (however this error reporting function was coming to that conclusion previously) and then emitting, for that grouping, the error that corresponds to the place that is most "specific".

In this case, a more "specific" means a Place that is not a prefix of a less "specific" Place. So I just decline to create and buffer an error if the Place for that error is a prefix of the Place that I already have a buffered error for.

There's a log statement that indicates an error is being suppressed and you still get the log statement showing which arguments the reporting function was called with before it suppresses it. There's also a comment attempting to explain the above logic on the field that stores the buffered errors.

This comment has been minimized.

@nikomatsakis

nikomatsakis Sep 7, 2018

Contributor

Hmm, @pnkfelix has an interesting point — or, at least, I that citing some point in a match arm as a "use" is more confusing than citing the match foo { itself.

Did you experiment with preferring the most general move? e.g., if the common prefix of the grouping is foo, perhaps preferring moves of foo?

That said, I don't think we should dump a ton of errors relating to a single move — I think that is more likely to confuse users. I could imagine trying to include more than one "use after move" point within the error itself.

e.g., we might display

 --> $DIR/issue-17385.rs:28:11
   |
LL |     drop(foo);
   |          --- value moved here
LL |     match foo { //~ ERROR use of moved value
   |           ^^^ value used here after move
LL | X(1) => (),
   |   - value also used here after move
   = note: move occurs because `foo` has type `X`, which does not implement the `Copy` trait

sorry the indentation doesn't line up, hopefully you get the idea

@nikomatsakis

nikomatsakis Sep 7, 2018

Contributor

Hmm, @pnkfelix has an interesting point — or, at least, I that citing some point in a match arm as a "use" is more confusing than citing the match foo { itself.

Did you experiment with preferring the most general move? e.g., if the common prefix of the grouping is foo, perhaps preferring moves of foo?

That said, I don't think we should dump a ton of errors relating to a single move — I think that is more likely to confuse users. I could imagine trying to include more than one "use after move" point within the error itself.

e.g., we might display

 --> $DIR/issue-17385.rs:28:11
   |
LL |     drop(foo);
   |          --- value moved here
LL |     match foo { //~ ERROR use of moved value
   |           ^^^ value used here after move
LL | X(1) => (),
   |   - value also used here after move
   = note: move occurs because `foo` has type `X`, which does not implement the `Copy` trait

sorry the indentation doesn't line up, hopefully you get the idea

This comment has been minimized.

@nikomatsakis

nikomatsakis Sep 7, 2018

Contributor

or perhaps with a kind of "note" like

 --> $DIR/issue-17385.rs:28:11
   |
LL |     drop(foo);
   |          --- value moved here
LL |     match foo { //~ ERROR use of moved value
   |           ^^^ value used here after move
   = note: move occurs because `foo` has type `X`, which does not implement the `Copy` trait
   = note: value is also used in other places after the move
LL | X(1) => (),
   |   -
@nikomatsakis

nikomatsakis Sep 7, 2018

Contributor

or perhaps with a kind of "note" like

 --> $DIR/issue-17385.rs:28:11
   |
LL |     drop(foo);
   |          --- value moved here
LL |     match foo { //~ ERROR use of moved value
   |           ^^^ value used here after move
   = note: move occurs because `foo` has type `X`, which does not implement the `Copy` trait
   = note: value is also used in other places after the move
LL | X(1) => (),
   |   -

This comment has been minimized.

@davidtwco

davidtwco Sep 7, 2018

Member

I didn't try the the most general move. When I was digging into the example case from the issue, I thought the best error there was the one with the "used in previous iteration of loop" message, and I noticed it was on the most specific place, which is why I used that as my heuristic.

@davidtwco

davidtwco Sep 7, 2018

Member

I didn't try the the most general move. When I was digging into the example case from the issue, I thought the best error there was the one with the "used in previous iteration of loop" message, and I noticed it was on the most specific place, which is why I used that as my heuristic.

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Sep 8, 2018

Rollup merge of rust-lang#53995 - davidtwco:issue-53807, r=nikomatsakis
Too many errors for incorrect move in loop with NLL enabled

Fixes rust-lang#53807.

r? @nikomatsakis

bors added a commit that referenced this pull request Sep 8, 2018

Auto merge of #54068 - Mark-Simulacrum:rollup, r=Mark-Simulacrum
Rollup of 11 pull requests

Successful merges:

 - #53851 (Limit the promotion of const fns to the libstd and the `rustc_promotable` attribute)
 - #53949 (Improve messages for un-closed delimiter errors)
 - #53960 (Fix incorrect outer function type parameter message)
 - #53988 (rustc_resolve: only prepend CrateRoot to a non-keyword segment.)
 - #53995 (Too many errors for incorrect move in loop with NLL enabled)
 - #53998 (rustc_codegen_llvm: don't assume offsets are always aligned.)
 - #54000 (Allow named lifetimes in async functions.)
 - #54011 (rustc_resolve: inject `uniform_paths` canary always on Rust 2018.)
 - #54024 (Fix compiling some rustc crates to wasm)
 - #54057 (Stabilize edition 2018; also updates Clippy and RLS)
 - #54064 (`&CStr`, not `CStr`, is the counterpart of `&str`)

Failed merges:

 - #54031 (A few cleanups and minor improvements to rustc_passes)

r? @ghost
@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 9, 2018

Contributor

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout issue-53807 (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self issue-53807 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: src/Cargo.lock (HEAD vs. heads/homu-tmp)
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 2774 and retry the command.
Auto-merging src/librustc_mir/borrow_check/mod.rs
Auto-merging src/librustc_mir/borrow_check/error_reporting.rs
Auto-merging src/Cargo.lock
CONFLICT (content): Merge conflict in src/Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

Contributor

bors commented Sep 9, 2018

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout issue-53807 (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self issue-53807 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: src/Cargo.lock (HEAD vs. heads/homu-tmp)
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 2774 and retry the command.
Auto-merging src/librustc_mir/borrow_check/mod.rs
Auto-merging src/librustc_mir/borrow_check/error_reporting.rs
Auto-merging src/Cargo.lock
CONFLICT (content): Merge conflict in src/Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@kennytm

This comment was marked as resolved.

Show comment
Hide comment
@kennytm

kennytm Sep 9, 2018

Member

@bors r-

The new test caused a UI error in #54068 (comment) because the emission order is unstable.

Member

kennytm commented Sep 9, 2018

@bors r-

The new test caused a UI error in #54068 (comment) because the emission order is unstable.

@davidtwco

This comment was marked as resolved.

Show comment
Hide comment
@davidtwco

davidtwco Sep 9, 2018

Member

@kennytm I'm struggling to reproduce this. I've rebased locally and ran rustc a bunch of times and compared the output (made a quick script to run diff on the output of a hundred or so runs) - there weren't any changes. Could it have been from another PR in the rollup?

Member

davidtwco commented Sep 9, 2018

@kennytm I'm struggling to reproduce this. I've rebased locally and ran rustc a bunch of times and compared the output (made a quick script to run diff on the output of a hundred or so runs) - there weren't any changes. Could it have been from another PR in the rollup?

@kennytm

This comment was marked as resolved.

Show comment
Hide comment
@kennytm

kennytm Sep 9, 2018

Member

@davidtwco It may matter that the error happens on i686-pc-windows-msvc (32-bit Windows MSVC). You may try to r=nikomatsakis if you are certain that this PR isn't the cause. Indeed the rollup includes #53949 and #53960 which may be relevant.

Member

kennytm commented Sep 9, 2018

@davidtwco It may matter that the error happens on i686-pc-windows-msvc (32-bit Windows MSVC). You may try to r=nikomatsakis if you are certain that this PR isn't the cause. Indeed the rollup includes #53949 and #53960 which may be relevant.

@davidtwco

This comment was marked as resolved.

Show comment
Hide comment
@davidtwco

davidtwco Sep 9, 2018

Member

Neither #53949 or #53960 seem like they'd cause the issue. I've done a build on x86_64-pc-windows-msvc (closest that I could get) and can't reproduce the issue - so it might be that specific platform for some strange reason? I'm not sure.

Member

davidtwco commented Sep 9, 2018

Neither #53949 or #53960 seem like they'd cause the issue. I've done a build on x86_64-pc-windows-msvc (closest that I could get) and can't reproduce the issue - so it might be that specific platform for some strange reason? I'm not sure.

@davidtwco

This comment was marked as resolved.

Show comment
Hide comment
@davidtwco

davidtwco Sep 11, 2018

Member

I've pushed a commit that addresses where this error ordering issue is likely stemming from.

Member

davidtwco commented Sep 11, 2018

I've pushed a commit that addresses where this error ordering issue is likely stemming from.

@nikomatsakis

r=me with comment

Show resolved Hide resolved src/librustc_mir/borrow_check/mod.rs Outdated
@nikomatsakis

This comment was marked as outdated.

Show comment
Hide comment
@nikomatsakis
Contributor

nikomatsakis commented Sep 11, 2018

@bors r+

@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 11, 2018

Contributor

📌 Commit 49d0121 has been approved by nikomatsakis

Contributor

bors commented Sep 11, 2018

📌 Commit 49d0121 has been approved by nikomatsakis

@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 14, 2018

Contributor

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout issue-53807 (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self issue-53807 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: src/Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/librustc_mir/borrow_check/mod.rs
Auto-merging src/librustc_errors/lib.rs
Auto-merging src/Cargo.lock
CONFLICT (content): Merge conflict in src/Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

Contributor

bors commented Sep 14, 2018

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout issue-53807 (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self issue-53807 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: src/Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/librustc_mir/borrow_check/mod.rs
Auto-merging src/librustc_errors/lib.rs
Auto-merging src/Cargo.lock
CONFLICT (content): Merge conflict in src/Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 18, 2018

Contributor

📌 Commit 88ca341 has been approved by nikomatsakis

Contributor

bors commented Sep 18, 2018

📌 Commit 88ca341 has been approved by nikomatsakis

@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 18, 2018

Contributor

⌛️ Testing commit 88ca341 with merge 35fc31f...

Contributor

bors commented Sep 18, 2018

⌛️ Testing commit 88ca341 with merge 35fc31f...

bors added a commit that referenced this pull request Sep 18, 2018

Auto merge of #53995 - davidtwco:issue-53807, r=nikomatsakis
Too many errors for incorrect move in loop with NLL enabled

Fixes #53807.

r? @nikomatsakis
@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 18, 2018

Contributor

💔 Test failed - status-travis

Contributor

bors commented Sep 18, 2018

💔 Test failed - status-travis

@rust-highfive

This comment was marked as outdated.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 18, 2018

Collaborator

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.
✓ uploaded script
travis_fold:end:step_upload_script
travis_fold:start:worker_info
Worker information
hostname: 13d4e6c1-dcff-437f-af1c-1ad9f04468b6@1.production-2-worker-org-gce-f3xj
instance: travis-job-852c3aa1-f953-402a-b58c-91b4a55159c1 travis-ci-connie-trusty-1512502258-986baf0 (via amqp)
startup: 24.763068003s
travis_fold:end:worker_info
travis_fold:start:system_info

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)

Collaborator

rust-highfive commented Sep 18, 2018

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.
✓ uploaded script
travis_fold:end:step_upload_script
travis_fold:start:worker_info
Worker information
hostname: 13d4e6c1-dcff-437f-af1c-1ad9f04468b6@1.production-2-worker-org-gce-f3xj
instance: travis-job-852c3aa1-f953-402a-b58c-91b4a55159c1 travis-ci-connie-trusty-1512502258-986baf0 (via amqp)
startup: 24.763068003s
travis_fold:end:worker_info
travis_fold:start:system_info

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)

@davidtwco

This comment was marked as outdated.

Show comment
Hide comment
@davidtwco
Member

davidtwco commented Sep 18, 2018

@bors retry #40474

@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 18, 2018

Contributor

⌛️ Testing commit 88ca341 with merge fb8efe3...

Contributor

bors commented Sep 18, 2018

⌛️ Testing commit 88ca341 with merge fb8efe3...

bors added a commit that referenced this pull request Sep 18, 2018

Auto merge of #53995 - davidtwco:issue-53807, r=nikomatsakis
Too many errors for incorrect move in loop with NLL enabled

Fixes #53807.

r? @nikomatsakis
@bors

This comment was marked as outdated.

Show comment
Hide comment
@bors

bors Sep 18, 2018

Contributor

💔 Test failed - status-travis

Contributor

bors commented Sep 18, 2018

💔 Test failed - status-travis

@rust-highfive

This comment was marked as outdated.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 18, 2018

Collaborator

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.
✓ uploaded script
travis_fold:end:step_upload_script
travis_fold:start:worker_info
Worker information
hostname: 47f072b0-ffce-4542-9fcb-5b4c122cd1ac@1.production-2-worker-org-gce-8ntg
instance: travis-job-f59c6552-d5e1-423e-9f78-bad62ee16e5a travis-ci-connie-trusty-1512502258-986baf0 (via amqp)
startup: 10.39765584s
travis_fold:end:worker_info
travis_fold:start:system_info
---
Attempting to download s3://rust-lang-ci-sccache2/docker/590b522632b069fe866315e86eb793e5b66d05851fa27ae56760b6d75b68b484d2151548988c8f28ab6dc3728c3834ac45e2484425bfedb84faef4af931d8bb3
[00:05:09] Attempting with retry: curl -f -L -C - -o /tmp/rustci_docker_cache https://s3-us-west-1.amazonaws.com/rust-lang-ci-sccache2/docker/590b522632b069fe866315e86eb793e5b66d05851fa27ae56760b6d75b68b484d2151548988c8f28ab6dc3728c3834ac45e2484425bfedb84faef4af931d8bb3
[00:05:09]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[00:05:09]                                  Dload  Upload   Total   Spent    Left  Speed
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

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)

Collaborator

rust-highfive commented Sep 18, 2018

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.
✓ uploaded script
travis_fold:end:step_upload_script
travis_fold:start:worker_info
Worker information
hostname: 47f072b0-ffce-4542-9fcb-5b4c122cd1ac@1.production-2-worker-org-gce-8ntg
instance: travis-job-f59c6552-d5e1-423e-9f78-bad62ee16e5a travis-ci-connie-trusty-1512502258-986baf0 (via amqp)
startup: 10.39765584s
travis_fold:end:worker_info
travis_fold:start:system_info
---
Attempting to download s3://rust-lang-ci-sccache2/docker/590b522632b069fe866315e86eb793e5b66d05851fa27ae56760b6d75b68b484d2151548988c8f28ab6dc3728c3834ac45e2484425bfedb84faef4af931d8bb3
[00:05:09] Attempting with retry: curl -f -L -C - -o /tmp/rustci_docker_cache https://s3-us-west-1.amazonaws.com/rust-lang-ci-sccache2/docker/590b522632b069fe866315e86eb793e5b66d05851fa27ae56760b6d75b68b484d2151548988c8f28ab6dc3728c3834ac45e2484425bfedb84faef4af931d8bb3
[00:05:09]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[00:05:09]                                  Dload  Upload   Total   Spent    Left  Speed
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

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)

@davidtwco

This comment has been minimized.

Show comment
Hide comment
@davidtwco
Member

davidtwco commented Sep 18, 2018

@bors retry #40474

@pnkfelix pnkfelix changed the title from Too many errors for incorrect move in loop with NLL enabled to Deduplicate errors for incorrect move in loop with NLL enabled Sep 18, 2018

@pnkfelix pnkfelix changed the title from Deduplicate errors for incorrect move in loop with NLL enabled to NLL: Deduplicate errors for incorrect move in loop Sep 18, 2018

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 19, 2018

Contributor

⌛️ Testing commit 88ca341 with merge 8f37677...

Contributor

bors commented Sep 19, 2018

⌛️ Testing commit 88ca341 with merge 8f37677...

bors added a commit that referenced this pull request Sep 19, 2018

Auto merge of #53995 - davidtwco:issue-53807, r=nikomatsakis
NLL: Deduplicate errors for incorrect move in loop

Fixes #53807.

r? @nikomatsakis
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 19, 2018

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 8f37677 to master...

Contributor

bors commented Sep 19, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 8f37677 to master...

@bors bors merged commit 88ca341 into rust-lang:master Sep 19, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@davidtwco davidtwco deleted the davidtwco:issue-53807 branch Sep 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment