Suggestions for miniz_oxide included in diagnostics in crate with no dependencies

[m-ou-se]

So, I was just chatting a bit with rustc and I was saying:

#![feature(never_type)]

fn a() -> Result<!, i32> {
    Err(1)
}

fn b() -> Result<u32, i32> {
    a().into()
}

fn main() {
    let _ = dbg!(b());
}

And then rustc said:

error[E0277]: the trait bound `Result<u32, i32>: From<Result<!, i32>>` is not satisfied
 --> src/main.rs:8:9
  |
8 |     a().into()
  |         ^^^^ the trait `From<Result<!, i32>>` is not implemented for `Result<u32, i32>`
  |

And I was like, sure, whatever you say.

But then rustc told me:

  = help: the following implementations were found:
            <Result<miniz_oxide::MZStatus, miniz_oxide::MZError> as From<&miniz_oxide::StreamResult>>
            <Result<miniz_oxide::MZStatus, miniz_oxide::MZError> as From<miniz_oxide::StreamResult>>

And I was like, excuse me what??

---

This crate has no dependencies. (Just an empty cargo new .. package.)

This happens on at least:

• rustc 1.55.0-nightly (014026d 2021-07-19)
• rustc 1.56.0-nightly (ccffcaf 2021-08-11)
• rustc 1.57.0-nightly (5d2a410 2021-09-04)

(On x86_64-unknown-linux-gnu and other platforms where backtrace is enabled in std, such that miniz_oxide is pulled in as a dependency of std.)

[m-ou-se]

miniz_oxide is a (private) dependency of std, but it shouldn't show up in diagnostics for any program using std like this.

[camelid]

And, even aside from miniz_oxide being a private dependency, the suggestions seem very unrelated to the input code. I guess just because they're From impls on Result? I would have thought other From impls would have come up too though.

[camelid]

I wonder if this is specific to never_type or not.

[hellow554]

I think the suggestion should not show up anymore if #87349 would have been merged.

Can you try that out? Would that be feasible for you?

[m-ou-se]

Ah that looks relevant. Trying that PR now..

[m-ou-se]

Nope. Same output with #87349.

[hellow554]

@In-line can you maybe say why your PR doesn't cover this case? :/

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-medium

[QuineDot]

I just got this too, in code with zero dependencies which is not at all exotic. All the non-std types here are just enums.

error[E0277]: the trait bound `Result<Option<Score>, build::Error>: From<Result<_, EntryError>>` is not satisfied
   --> src/build.rs:105:33
    |
105 |         Err(EntryError::InvalidScore).into()
    |                                       ^^^^ the trait `From<Result<_, EntryError>>` is not implemented for `Result<Option<Score>, build::Error>`
    |
    = help: the following implementations were found:
              <Result<miniz_oxide::MZStatus, miniz_oxide::MZError> as From<&miniz_oxide::StreamResult>>
              <Result<miniz_oxide::MZStatus, miniz_oxide::MZError> as From<miniz_oxide::StreamResult>>
    = note: required because of the requirements on the impl of `Into<Result<Option<Score>, build::Error>>` for `Result<_, EntryError>`

"miniz_oxide" doesn't cry out "implicit stdlib thing" so I spent awhile trying to figure out how an unrelated project was polluting this one, running cargo clean in various places, etc.

[jirutka]

miniz_oxide is a (private) dependency of std, but it shouldn't show up in diagnostics for any program using std like this.

The real question is, why is minz_oxide pulled into a trivial program (binary) in the first place? It’s not a small dependency.