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

Type inference regression from 1.14.0 to 1.15.0 #41194

Closed
jethrogb opened this issue Apr 10, 2017 · 4 comments
Closed

Type inference regression from 1.14.0 to 1.15.0 #41194

jethrogb opened this issue Apr 10, 2017 · 4 comments
Labels
regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@jethrogb
Copy link
Contributor

jethrogb commented Apr 10, 2017

This code:

struct S {
    v: Vec<(u32, Vec<u32>)>,
}

impl S {
    pub fn remove(&mut self, i: u32) -> Option<std::vec::Drain<u32>> {
        self.v.get_mut(i as _ /*usize*/).map(|&mut (_, ref mut v2)| {
            v2.drain(..)
        })
    }
}

stopped compiling in 1.15.0 with:

error: the type of this value must be known in this context
 --> src/main.rs:8:16
  |
8 |             v2.drain(..)
  |                ^^^^^

If you change the cast on line 7 to the concrete type usize, it compiles fine on 1.15.0 (and later)

@alexcrichton alexcrichton added the regression-from-stable-to-stable Performance or correctness regression from one stable version to another. label Apr 10, 2017
@alexcrichton
Copy link
Member

Almost surely caused by #36340, so nominating for libs discussion.

@jethrogb we're unlikely to revert the change as this is a routine "type inference can break from time to time", but if you have difficulty fixing this please let us know as it'd affect our discussion!

@alexcrichton alexcrichton added I-nominated T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Apr 10, 2017
@jethrogb
Copy link
Contributor Author

It turned out to be an easy fix, but here's some points for your discussion:

  • The fix would've been easier if the error was in the right place.
  • If this code would've been in a public crate on crates.io at the time that PR was considered, what would've happenned?

@nagisa
Copy link
Member

nagisa commented Apr 10, 2017

If this code would've been in a public crate on crates.io at the time that PR was considered, what would've happenned?

crater would’ve caught it and we would send PR/ping before the relevant version of rustc gets released as a stable version.

@alexcrichton
Copy link
Member

Ok we discussed this during libs triage the other day, and the conclusion was to close this. The known regressions have been fixed and we'd otherwise categorize this under "known breakage".

If this comes up over time though please let us know as we're always interested in understanding when changes like this cause problems!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants