Cargo doc regression in crates that include #![deny(unused_imports)]

[dtolnay]

#![deny(unused_imports)]

use std::fs::File;

pub fn f() {
    let _: File;
}

cargo doc of the above lib.rs works up through cargo +nightly-2018-06-17 doc. As of cargo +nightly-2018-06-18 doc it fails with:

$ cargo +nightly-2018-06-18 doc
 Documenting unused-imports v0.0.0
error: unused import: `std::fs::File`
 --> src/lib.rs:3:5
  |
3 | use std::fs::File;
  |     ^^^^^^^^^^^^^
  |
note: lint level defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(unused_imports)]
  |         ^^^^^^^^^^^^^^

error: Compilation failed, aborting rustdoc

error: Could not document `unused-imports`.

[dtolnay]

That commit range: ae46aef...86a8f1a. Mentioning @QuietMisdreavus and @GuillaumeGomez who were touching librustdoc in that range and @petrochenkov who reviewed #51425.

[GuillaumeGomez]

The problem is a bit complex (to say the least)...

[QuietMisdreavus]

The problem was the introduction of the intra_doc_links_resolution_failure lint, which caused rustdoc to stop capping lints:

rust/src/librustdoc/core.rs

Line 216 in f790780

lint_cap: Some(lint::Forbid),

The sample in this issue (and the regression in winapi in #51689) both explicitly deny the lint, despite us allowing it in rustdoc ahead of time. We need a way to disable this lint (and potentially any others that are affected by everybody-loops?) when rustdoc is running. Alternately, some kind of "porous lint cap" that still lets us fire the intra-doc-links lint? Is that possible with the current system?

[GuillaumeGomez]

It requires investigation but I think we can.

[marshallpierce]

unused_extern_crates causes a similar problem (see marshallpierce/rust-base64#64). Same root cause, or should I open a separate issue?

[GuillaumeGomez]

No, it's the same source. I know what the problem is, just need to fix it when I have time.