Closed
Description
On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type.
I tried this code:
extern crate bitflags;
fn test(r: Result<Option<()>, &'static str>) { }
fn main() { test(Ok(())); }
I expected to see this happen: (stable rust)
$ rustup default stable
$ cargo build
Compiling rust-sample v0.1.0 (file:///[...]/rust-sample)
error[E0308]: mismatched types
--> src/main.rs:3:21
|
3 | fn main() { test(Ok(())); }
| ^^
| |
| expected enum `std::option::Option`, found ()
| help: try using a variant of the expected type: `Some(())`
|
= note: expected type `std::option::Option<()>`
found type `()`
Instead, this happened: (nightly)
$ rustup default nightly
$ cargo build
Compiling rust-sample v0.1.0 (file:///[...]/rust-sample)
error[E0308]: mismatched types
--> src/main.rs:3:21
|
3 | fn main() { test(Ok(())); }
| ^^
| |
| expected enum `bitflags::<unnamed>::option::Option`, found ()
| help: try using a variant of the expected type: `bitflags::<unnamed>::prelude::v1::Some(())`
|
= note: expected type `bitflags::<unnamed>::option::Option<()>`
found type `()`
Meta
rustc --version --verbose
:
rustc 1.23.0-nightly (5041b3bb3 2017-11-19)
binary: rustc
commit-hash: 5041b3bb3d953a14f32b15d1e41341c629acae12
commit-date: 2017-11-19
host: x86_64-unknown-linux-gnu
release: 1.23.0-nightly
LLVM version: 4.0
Activity
arielb1 commentedon Nov 20, 2017
Confirming - broken on nightly (1.23), good on beta.
pnkfelix commentedon Dec 1, 2017
bisected across nightlys: bug was injected between
rustc 1.23.0-nightly (02004ef78 2017-11-08)
andrustc 1.23.0-nightly (d6b06c63a 2017-11-09)
pnkfelix commentedon Dec 1, 2017
Skimming output from
git log 02004ef78^..d6b06c63a
, there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.Mark-Simulacrum commentedon Dec 1, 2017
This is recent enough that we should be able to run bisect-rust on it (cc @est31).
est31 commentedon Dec 1, 2017
#45452 it is cc @estebank @nikomatsakis .
estebank commentedon Dec 1, 2017
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
est31 commentedon Dec 1, 2017
I have misread @pnkfelix 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
estebank commentedon Dec 1, 2017
@est31 I tried it locally in the meantime and I can confirm it is not :)
est31 commentedon Dec 1, 2017
Okay so the bug dates as far back as efceda2 from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
37 remaining items