Change:
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: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , 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.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
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.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as 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 :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: 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...
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 crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
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.
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 ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .

Discussion:
assert_eq!(cnum, LOCAL_CRATE); let mut visible_parent_map: DefIdMap<DefId> = DefIdMap(); <ins> // Issue 46112: We want the map to prefer the shortest // paths when reporting the path to an item. Therefore we // build up the map via a breadth-first search (BFS), // which naturally yields minimal-length paths. // // Note that it needs to be a BFS over the whole forest of // crates, not just each individual crate; otherwise you // only get paths that are locally minimal with respect to // whatever crate we happened to encounter first in this // traversal, but not globally minimal across all crates. let bfs_queue = &mut VecDeque::new(); </ins> for &cnum in tcx.crates().iter() { // Ignore crates without a corresponding local `extern crate` item. if tcx.missing_extern_crate_item(cnum) { continue } <del> let bfs_queue = &mut VecDeque::new(); </del> <ins> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); } // (restrict scope of mutable-borrow of `visible_parent_map`) { </ins> let visible_parent_map = &mut visible_parent_map; let mut add_child = |bfs_queue: &mut VecDeque<_>, child: &def::Export,

} }; <del> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); </del> while let Some(def) = bfs_queue.pop_front() { for child in tcx.item_children(def).iter() { add_child(bfs_queue, child, def);

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="lib"] pub extern crate core; </ins>

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Issue 46112: An extern crate pub reexporting libcore was causing // paths rooted from `std` to be misrendered in the diagnostic output. // ignore-windows // aux-build:xcrate_issue_46112_rexport_core.rs extern crate xcrate_issue_46112_rexport_core; fn test(r: Result<Option<()>, &'static str>) { } fn main() { test(Ok(())); } //~^ mismatched types </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-46112.rs:19:21 | 19 | 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 `()` error: aborting due to previous error </ins>