rustdoc: only show intra_doc_link_resolution_failure lints for items being documented
#51684
Comments
QuietMisdreavus
added
T-rustdoc
|
cc @GuillaumeGomez since you implemented both the lint and the warning that preceded it. |
|
cc #43466 as well since it's an intra-doc-link problem |
QuietMisdreavus
added
C-bug
|
Just ran into this. I would like to see these capped to warn like they are normally for lints on dependency crates, rather than preventing a doc build on my crate for something I can't control. |
|
You can now play with cap-lints with rustdoc just like you would with rustc. However, this issue is a separate problem which needs to be fixed on its own. |
|
It would be good, I think, to automatically suppress this lint for all dependent crates by default. Perhaps off-topic, but this lint seems to be firing a lot for some crates (crossbeam, regex, and (I think) std). Many of these look like markdown links, which presumably we should not be firing the lint for? |
|
It took a bit of a refactor, but i've posted #52800 to solve this issue. |
rustdoc: refactor how passes are structured, and turn intra-doc-link collection into a pass This builds on #52751 and should not be merged until that finally finishes the bors queue Part 2 of my passes refactor. This introduces the concept of an "early pass", which is run right before exiting the compiler context. This is important for passes that may want to ask the compiler about things. For example, i took out the intra-doc-link collection and turned it into a early pass. I also made the `strip-hidden`, `strip-private` and `strip-priv-imports` passes occur as early passes, so that intra-doc-link collection wouldn't run on docs that weren't getting printed. Fixes #51684, technically #51468 too but that version of `h2` hits a legit intra-link error after that `>_>` r? @rust-lang/rustdoc
One thing i noticed about this lint is that it's firing for items that aren't even being exported. For example, in this build log, there are a lot of repeat hits for the
cfg_if!macro, even though i would not expect all of these crates to be re-exporting the macro. In one particular situation, it seems to have caused a crate with#![deny(warnings)]on it to fail to build, just because of this dependency! We should probably wait to emit these lints until the passes which strip items have been run, to reduce some of these erroneous reports.The text was updated successfully, but these errors were encountered: