Skip to content

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Jun 13, 2017

Rewrite the for loop desugaring to avoid contaminating the inference results. Under the older desugaring, for x in vec![] { .. } would erroneously type-check, even though the type of vec![] is unconstrained. (written by @nikomatsakis)

@rust-highfive
Copy link
Contributor

r? @arielb1

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

@eddyb eddyb added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jun 13, 2017
@arielb1
Copy link
Contributor

arielb1 commented Jun 13, 2017

This looks like a rather fragile area of code. I'm ok with the changes, but I'll rather r? @nikomatsakis

@arielb1 arielb1 added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 13, 2017
@nikomatsakis
Copy link
Contributor

@Zoxc can we add a run-pass test checking the order of drops with comments explaining the expected order?

@nikomatsakis
Copy link
Contributor

We probably would need this to be in relnotes, presuming it lands. Tagging it as such.

@nikomatsakis nikomatsakis added the relnotes Marks issues that should be documented in the release notes of the next release. label Jun 14, 2017
@nikomatsakis
Copy link
Contributor

@Zoxc can you also add a run-pass test case like this? (It fails for me on nightly/beta, not on stable)

fn main() {
    let mut sum = 0;
    for i in Vec::new() {
        sum += i;
    }
}

Similarly a compile-fail test like this, which also fails on stable, but works on beta/nightly:

fn main() {
    for i in Vec::new() { } //~ ERROR type annotations needed
}

r=me with those tests

@nikomatsakis nikomatsakis removed the relnotes Marks issues that should be documented in the release notes of the next release. label Jun 14, 2017
@nikomatsakis
Copy link
Contributor

Removing relnotes, I didn't realize that this behavior had never contaminated stable.

@brson
Copy link
Contributor

brson commented Jun 15, 2017

#42265 needs to be reverted from beta as this is applied

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 15, 2017

📌 Commit e4baa26 has been approved by nikomatsakis

@nikomatsakis
Copy link
Contributor

I took the liberty of adding a few comments to the test for posterity.

@nikomatsakis
Copy link
Contributor

@bors r-

oops, forgot one test.

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 15, 2017

📌 Commit f11cf60 has been approved by nikomatsakis

@nikomatsakis
Copy link
Contributor

@bors r+

@nikomatsakis
Copy link
Contributor

tidy error:

[00:02:09] tidy error: /checkout/src/librustc/hir/lowering.rs:2192: line longer than 100 chars

@@ -2170,11 +2170,13 @@ impl<'a> LoweringContext<'a> {
// let result = match ::std::iter::IntoIterator::into_iter(<head>) {
// mut iter => {
// [opt_ident]: loop {
// let <pat> = match ::std::iter::Iterator::next(&mut iter) {
// ::std::option::Option::Some(val) => val,
// let mut _next;
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the _next name disable a "unused mut" warning?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 22, 2017

📌 Commit 1409e70 has been approved by nikomatsakis

bors added a commit that referenced this pull request Jun 22, 2017
Change the for-loop desugar so the `break` does not affect type inference. Fixes #42618

Rewrite the `for` loop desugaring to avoid contaminating the inference results. Under the older desugaring, `for x in vec![] { .. }` would erroneously type-check, even though the type of `vec![]` is unconstrained. (written by @nikomatsakis)
@bors
Copy link
Collaborator

bors commented Jun 22, 2017

⌛ Testing commit 1409e70 with merge ab5bec2...

@bors
Copy link
Collaborator

bors commented Jun 22, 2017

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

@bors bors merged commit 1409e70 into rust-lang:master Jun 22, 2017
@brson brson added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Jun 22, 2017
@brson brson mentioned this pull request Jun 22, 2017
@alexcrichton alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jun 22, 2017
bors added a commit that referenced this pull request Jun 25, 2017
[beta] backports

- #42785
- #42740
- #42735
- #42728
- #42695
- #42659
- #42634
- #42566

I just unilaterally accepted all the non-accepted nominations. Everything picked cleanly.

Still testing locally.

cc @rust-lang/compiler

r? @alexcrichton
bors added a commit that referenced this pull request Jun 25, 2017
[beta] backports

- #42785
- #42740
- #42735
- #42728
- #42695
- #42659
- #42634
- #42566

I just unilaterally accepted all the non-accepted nominations. Everything picked cleanly.

Still testing locally.

cc @rust-lang/compiler

r? @alexcrichton
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Jun 27, 2017
…ielb1

change binding name of for loop lowering to appease clippy

With the latest change to for loop lowering (rust-lang#42634), a `_next` binding was introduced.
Unfortunately, this [disturbs](https://github.com/Manishearth/rust-clippy/issues/1846) clippy's `used_underscore_binding` lint. This commit just renames the binding to `__next` so clippy will be happy. It should have no other effect.
bors added a commit that referenced this pull request Jun 27, 2017
[beta] backports

Reopening #42841 as a new PR due to bors flakiness.

- #42785
- #42740
- #42735
- #42728
- #42695
- #42659
- #42634
- #42566

I just unilaterally accepted all the non-accepted nominations. Everything picked cleanly.
bors added a commit that referenced this pull request Jun 27, 2017
[beta] backports

Reopening #42841 as a new PR due to bors flakiness.

- #42785
- #42740
- #42735
- #42728
- #42695
- #42659
- #42634
- #42566

I just unilaterally accepted all the non-accepted nominations. Everything picked cleanly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants