Mismatched type error: type of crate instead of std is displayed #46112

SWW13 · 2017-11-20T12:25:33Z

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

The text was updated successfully, but these errors were encountered:

arielb1 · 2017-11-20T16:48:14Z

Confirming - broken on nightly (1.23), good on beta.

pnkfelix · 2017-12-01T16:12:58Z

bisected across nightlys: bug was injected between rustc 1.23.0-nightly (02004ef78 2017-11-08) and rustc 1.23.0-nightly (d6b06c63a 2017-11-09)

pnkfelix · 2017-12-01T16:21:29Z

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 · 2017-12-01T16:59:38Z

This is recent enough that we should be able to run bisect-rust on it (cc @est31).

est31 · 2017-12-01T17:24:38Z

Searching in 7 commits; about 3 steps
Checking
  |                        expected enum `std::option::Option`, found ()
INFO:bisect: tested fd9ecfdfd from Thu,  9 Nov 2017 04:14:28 +0000: test failed: true
Checking
  |                        expected enum `std::option::Option`, found ()
INFO:bisect: tested da3fbe750 from Wed,  8 Nov 2017 22:27:06 +0000: test failed: true
Checking
  |                        expected enum `std::option::Option`, found ()
INFO:bisect: tested 02004ef78 from Wed,  8 Nov 2017 20:00:41 +0000: test failed: true
searched commits 02004ef78383cb174a41df7735a552823fa10b90 through d6b06c63a0c735fc15c9c704422375c17b7c7e12
regression in 0; Some(Commit { sha: "02004ef78383cb174a41df7735a552823fa10b90", date: 2017-11-08T20:00:41Z, summary: "Auto merge of #45452 - estebank:colon-typo, r=nikomatsakis" })

#45452 it is cc @estebank @nikomatsakis .

estebank · 2017-12-01T18:06:54Z

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 · 2017-12-01T18:20:03Z

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 · 2017-12-01T18:40:43Z

@est31 I tried it locally in the meantime and I can confirm it is not :)

est31 · 2017-12-01T18:44:47Z

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 :).

Mark-Simulacrum · 2017-12-01T18:49:44Z

@pnkfelix suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?

est31 · 2017-12-01T18:56:38Z

@Mark-Simulacrum I should probably have read the original issue more closely :). @estebank sorry for pinging you!

Searching in 7 commits; about 3 steps
Checking
INFO:bisect: tested fd9ecfdfd from Thu,  9 Nov 2017 04:14:28 +0000: test failed: false
Checking
  |                        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<()>`
INFO:bisect: tested f1ea23e2c from Thu,  9 Nov 2017 18:14:48 +0000: test failed: true
Checking
INFO:bisect: tested 98e791e7e from Thu,  9 Nov 2017 15:42:26 +0000: test failed: false
searched commits 02004ef78383cb174a41df7735a552823fa10b90 through d6b06c63a0c735fc15c9c704422375c17b7c7e12
regression in 5; Some(Commit { sha: "f1ea23e2cc72cafad1dc25a06c09ec2de8e323eb", date: 2017-11-09T18:14:48Z, summary: "Auto merge of #45725 - alexcrichton:std-less-rand, r=dtolnay" })

It seems to be #45725 cc @alexcrichton

pnkfelix · 2017-12-04T17:02:24Z

In particular, I have bisected it down to the commit: 6bc8f16

I have been trying to further dissect that commit to figure out why it causes the change we observe here.

My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...

pnkfelix · 2017-12-05T16:05:52Z

Hmm. Its something more subtle than a hashmap-related bug.

In particular, I can reproduce the old behavior on master by just linking in the old librand crate into libstd (in addtion to linking in the one from crates.io; doing this requires changing the name of the old librand), without making any actual calls into the old librand crate.

That, to me, seems very strange. I'm now trying to reduce down the size of the librand crate that I am linking in (while still causing this delta in behavior).

nikomatsakis · 2017-12-07T15:31:57Z

triage: P-high

… whole crate forest.

Fix visible_parent_map to choose globally minimal paths Fix #46112: visible_parent_map construction needs a BFS over whole crate forest to get globally minimal paths. (There are other latent bugs that were e.g. causing this test case to have weirdness like `<unnamed>` in the diagnostic output. Those bugs are not fixed here, since they are issues long-standing in the stable channel.)

SWW13 · 2017-12-15T09:58:29Z

I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.

error[E0308]: mismatched types
   --> src/bus/mod.rs:350:25
    |
350 |                         Err(BusError::ServiceTimeout(elapsed))
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `std::option::Option`, found enum `std::result::Result`
    |
    = note: expected type `std::option::Option<_>`
               found type `std::result::Result<_, bus::BusError>`

error[E0308]: mismatched types
   --> src/bus/mod.rs:339:37
    |
339 |                     .and_then(|len| T::from_bytes(&self.buffer[0..len]))
    |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `serde::export::Option`, found enum `serde::export::Result`
    |
    = note: expected type `serde::export::Option<_>`
               found type `serde::export::Result<C, services::ServiceError>`

pnkfelix · 2017-12-19T12:22:14Z

@SWW13 is that a regression from the stable channel?

While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at std), I want to triage this appropriately.

pnkfelix · 2017-12-19T12:23:08Z

Hmm I guess since @SWW13 is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described ~~behavior on~~ regression compared to the stable channel.

SWW13 · 2017-12-19T13:20:59Z

@SWW13 is that a regression from the stable channel?

cargo +stable build gives me:

error[E0308]: mismatched types
   --> src/bus/mod.rs:339:37
    |
339 |                     .and_then(|len| T::from_bytes(&self.buffer[0..len]))
    |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `serde::export::Option`, found enum `serde::export::Result`
    |
    = note: expected type `serde::export::Option<_>`
               found type `serde::export::Result<C, services::ServiceError>`

error[E0308]: mismatched types
   --> src/bus/mod.rs:350:25
    |
350 |                         Err(BusError::ServiceTimeout(elapsed))
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `serde::export::Option`, found enum `serde::export::Result`
    |
    = note: expected type `serde::export::Option<_>`
               found type `serde::export::Result<_, bus::BusError>`

cargo +nightly build seems to work now:

error[E0308]: mismatched types
   --> src/bus/mod.rs:339:37
    |
339 |                     .and_then(|len| T::from_bytes(&self.buffer[0..len]))
    |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `std::option::Option`, found enum `std::result::Result`
    |
    = note: expected type `std::option::Option<_>`
               found type `std::result::Result<C, services::ServiceError>`

error[E0308]: mismatched types
   --> src/bus/mod.rs:350:25
    |
350 |                         Err(BusError::ServiceTimeout(elapsed))
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `std::option::Option`, found enum `std::result::Result`
    |
    = note: expected type `std::option::Option<_>`
               found type `std::result::Result<_, bus::BusError>`

Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.

Sorting by crate-num should ensure that we favor `std::foo::bar` over `any_other_crate::foo::bar`. Interestingly, *this* change had a much larger impact on our internal test suite than PR rust-lang#46708 (which was my original fix to rust-lang#46112).

Sorting by crate-num should ensure that we favor `std::foo::bar` over `any_other_crate::foo::bar`. Interestingly, *this* change had a much larger impact on our internal test suite than PR rust-lang#46708 (which was my original fix to rust-lang#46112). ---- (This is cherry-pick of aa030dd to beta.)

…re::` The reason we see `core::` even after visiting the `std` crate first is the special case code that looks like this: ```rust Entry::Occupied(mut entry) => { // If `child` is defined in crate `cnum`, ensure // that it is mapped to a parent in `cnum`. if child.krate == cnum && entry.get().krate != cnum { entry.insert(parent); } } ``` This causes items to be associated with the crates they were originally defined in, even if we had encountered them during the traversal of an earlier crate. (Having said that, I am not clear on why this same logic does not apply when both rust-lang#46708 and rust-lang#46838 have been applied. But at this point, I am just happy to have a plausible explanation for why we see `core::foo::bar` in the output for these tests, and want to focus on getting this fix for rust-lang#46112 backported to beta.)

Followup for #46112. Sorting by crate-num should ensure that we favor `std::foo::bar` over `any_other_crate::foo::bar`. Interestingly, *this* change had a much larger impact on our internal test suite than PR #46708 (which was my original fix to #46112).

…woerister Backport 46112 fix to beta Its probably easiest to focus on the diff rather than the commit series. If you prefer I could squash them, but I figured preserving the cherry-picking will make it easier to relate what has happened here to what happens on the `master` branch. Note: This is a backport of *just* #46838. It does not include #46708 (which we may end up wanting to revert). Fix #46112

dtolnay · 2017-12-24T21:24:48Z

This looks like a duplicate of #45070. That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.

ExpHP · 2017-12-24T22:52:56Z

When I bisected the nightlies by hand on #45070 I ended up with a range (d93036a...dead08c) that does not include the rand commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect?

Expectation: ................XXXXXXXXXXXXXXXXXXXXXXX
    Reality: ................XXX....X..X..XXXXXXXXXX
             (<-- past)                (present -->)

Legend:
   X: Commit where test fails
   .: Commit where test succeeds

I wonder whether merely linking rand affects #45070 in the same way as it affected this issue.

arielb1 · 2017-12-24T23:15:53Z

@dtolnay

Any evidence of this problem existing with the newest nightly?

dtolnay · 2017-12-25T02:22:20Z

All the cases I tried seem to have been fixed by #46708 and #46838. Nicely done! I reported one follow-up in #46991.

arielb1 added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 20, 2017

TimNN added the C-bug Category: This is a bug. label Nov 21, 2017

arielb1 added regression-from-stable-to-beta Performance or correctness regression from stable to beta. and removed regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Nov 30, 2017

arielb1 assigned pnkfelix Nov 30, 2017

Mark-Simulacrum added this to the 1.23 milestone Dec 5, 2017

rust-highfive added the P-high High priority label Dec 7, 2017

sinkuu mentioned this issue Dec 10, 2017

Bitflags pollute error message with its version of ops::FnOnce #46619

Closed

pnkfelix added a commit to pnkfelix/rust that referenced this issue Dec 13, 2017

Fix rust-lang#46112: visible_parent_map construction needs a BFS over…

43406d2

… whole crate forest.

pnkfelix added a commit to pnkfelix/rust that referenced this issue Dec 13, 2017

Regression test for issue rust-lang#46112.

35bcd99

pnkfelix mentioned this issue Dec 13, 2017

Fix visible_parent_map to choose globally minimal paths #46708

Merged

bors closed this as completed in #46708 Dec 14, 2017

estebank reopened this Dec 15, 2017

pnkfelix mentioned this issue Dec 19, 2017

Followup for #46112. #46838

Merged

pnkfelix added a commit to pnkfelix/rust that referenced this issue Dec 20, 2017

Regression test for issue rust-lang#46112.

7db6372

pnkfelix mentioned this issue Dec 20, 2017

compiler code cleanup: replace metas: HashMap with IndexVec #46876

Closed

pnkfelix mentioned this issue Dec 21, 2017

Backport 46112 fix to beta #46905

Merged

dtolnay added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed regression-from-stable-to-beta Performance or correctness regression from stable to beta. labels Dec 24, 2017

dtolnay mentioned this issue Dec 24, 2017

Regression in what path is chosen for error messages #45070

Closed

dtolnay mentioned this issue Dec 25, 2017

Avoid path to macro-generated extern crate in error messages #46991

Open

dtolnay closed this as completed Dec 25, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mismatched type error: type of crate instead of std is displayed #46112

Mismatched type error: type of crate instead of std is displayed #46112

SWW13 commented Nov 20, 2017

arielb1 commented Nov 20, 2017

pnkfelix commented Dec 1, 2017

pnkfelix commented Dec 1, 2017

Mark-Simulacrum commented Dec 1, 2017

est31 commented Dec 1, 2017

estebank commented Dec 1, 2017

est31 commented Dec 1, 2017

estebank commented Dec 1, 2017

est31 commented Dec 1, 2017

Mark-Simulacrum commented Dec 1, 2017

est31 commented Dec 1, 2017

pnkfelix commented Dec 4, 2017

pnkfelix commented Dec 5, 2017

nikomatsakis commented Dec 7, 2017

SWW13 commented Dec 15, 2017

pnkfelix commented Dec 19, 2017

pnkfelix commented Dec 19, 2017 •

edited

Loading

SWW13 commented Dec 19, 2017

dtolnay commented Dec 24, 2017

ExpHP commented Dec 24, 2017 •

edited

Loading

arielb1 commented Dec 24, 2017

dtolnay commented Dec 25, 2017

Mismatched type error: type of crate instead of std is displayed #46112

Mismatched type error: type of crate instead of std is displayed #46112

Comments

SWW13 commented Nov 20, 2017

Meta

arielb1 commented Nov 20, 2017

pnkfelix commented Dec 1, 2017

pnkfelix commented Dec 1, 2017

Mark-Simulacrum commented Dec 1, 2017

est31 commented Dec 1, 2017

estebank commented Dec 1, 2017

est31 commented Dec 1, 2017

estebank commented Dec 1, 2017

est31 commented Dec 1, 2017

Mark-Simulacrum commented Dec 1, 2017

est31 commented Dec 1, 2017

pnkfelix commented Dec 4, 2017

pnkfelix commented Dec 5, 2017

nikomatsakis commented Dec 7, 2017

SWW13 commented Dec 15, 2017

pnkfelix commented Dec 19, 2017

pnkfelix commented Dec 19, 2017 • edited Loading

SWW13 commented Dec 19, 2017

dtolnay commented Dec 24, 2017

ExpHP commented Dec 24, 2017 • edited Loading

arielb1 commented Dec 24, 2017

dtolnay commented Dec 25, 2017

pnkfelix commented Dec 19, 2017 •

edited

Loading

ExpHP commented Dec 24, 2017 •

edited

Loading