Regression: missing_debug_implementations linting on private items when used as parameter in trait impl

[Manishearth]

(As a lint regression it is not a true "breaking" regression, but it's still strange behavior, categorizing as a regression.)

Code

(Also reproducible with cargo check --no-default-features in https://github.com/unicode-org/icu4x/tree/3a00b1efc12d8fac2aa84b04f85508e3b75bca4c/provider/datagen)

#[deny(missing_debug_implementations)]
#[allow(unused)]

pub mod foo {
    struct Bar;

    impl<'a> TryFrom<Bar> for u8 {
        type Error = ();
        fn try_from(o: Bar) -> Result<Self, ()> {
            unimplemented!()
        }
    }
}

[09:57:34] मanishearth@manishearth-glaptop2 ~/sand/crates/bar O_o 
$ cargo +nightly c
    Checking bar v0.1.0 (/home/manishearth/sand/crates/bar)
error: type does not implement `Debug`; consider adding `#[derive(Debug)]` or a manual implementation
 --> src/lib.rs:5:5
  |
5 |     struct Bar;
  |     ^^^^^^^^^^^
  |
note: the lint level is defined here
 --> src/lib.rs:1:8
  |
1 | #[deny(missing_debug_implementations)]
  |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `bar` (lib) due to previous error

Version it worked on

It most recently worked on: nightly-2023-05-06

Version with regression

rustc --version: nightly-2023-05-07

[Manishearth]

searched nightlies: from nightly-2023-05-05 to nightly-2023-05-07
regressed nightly: nightly-2023-05-07
searched commit range: f9a6b71...a77c552
regressed commit: 31a4f2d

bisected with cargo-bisect-rustc v0.6.6

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start 2023-05-05 --end 2023-05-07 -- check --no-default-features 

[Manishearth]

Regression comes from #110907

[Manishearth]

The issue is that Bar now appears in the type parameters of the the TryFrom impl of u8. However that doesn't mean it's reachable, this is effectively a "private" TryFrom impl: there is no way to invoke this impl to get this type.

[petrochenkov]

In theory #110907 wasn't supposed to change the algorithm, only to make the collected data more detailed.
So if we didn't reach type parameters previously, then we shouldn't reach them now, and vice versa.

cc @Bryanskiy, we need to figure out why there's a difference.

[petrochenkov]

However that doesn't mean it's reachable, this is effectively a "private" TryFrom impl: there is no way to invoke this impl to get this type.

Type inference is sometimes smarter than you'd expect, see e.g. examples in #57344, so we may have to conservatively consider generic arguments of impls as reachable.

[petrochenkov]

In general, the reachable set is an upper limit rather than something that can be determined precisely, so we can overshoot slightly (or not so slightly in cases where macros 2.0 are in scope), so lints based on it should generally be ready to require doc comments / stability attributes / copy or debug imps on items where they are not strictly necessary.

[Manishearth]

Yeah, that seems fair. Stepping back, perhaps the question becomes: should this lint be really dealing with reachability or actual "intentional" publicity?