Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#![deny(warnings)] affects doc warnings #54316

Closed
kpp opened this issue Sep 18, 2018 · 7 comments
Closed

#![deny(warnings)] affects doc warnings #54316

kpp opened this issue Sep 18, 2018 · 7 comments
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@kpp
Copy link
Contributor

kpp commented Sep 18, 2018

On rustc 1.30.0-nightly (e4ba1d41e 2018-09-15) #![deny(warnings)] affects doc warnings, which makes it impossible to build docs. It may take huge time for a crate to fix these warnings. See tokio-rs/tokio#437

Possible solution: distinguish warnings in code and warnings in docs by providing #![deny(doc_warnings)]

@matthewjasper
Copy link
Contributor

@kpp
Copy link
Contributor Author

kpp commented Sep 18, 2018

None of these helped:

#![deny(missing_docs, missing_debug_implementations, warnings)]
#![doc(allow(warnings))]
#![deny(missing_docs, missing_debug_implementations, warnings)]
#![doc(test(attr(allow(warnings))))]
#![deny(missing_docs, missing_debug_implementations, warnings)]
#![doc(attr(allow(warnings)))]

I want to make warnings be warnings again when I call cargo doc.

@QuietMisdreavus QuietMisdreavus added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Sep 18, 2018
@QuietMisdreavus
Copy link
Member

#![doc(test(attr(...)))] only affects doctests, not the crate. There is no real mechanism for the issue as requested right now.

If you're using #[doc(cfg(...))] then #[cfg(rustdoc)] will be available, and you can use #![cfg_attr(rustdoc, deny(warnings))]. However, that requires a nightly feature right now, and may not be applicable to everyone.

My suggestion for affected crates is to set #![warn(intra_doc_link_resolution_failure)], which is always the lint at fault in situations like this. This lint is only emitted by rustdoc, so it won't affect regular compilation.

The other thing i noticed in your linked issue is that it's affecting dependencies when running cargo doc. Cargo is supposed to set --cap-lints allow when documenting dependencies now; is this issue still happening when you're documenting downstream crates?

I would be open to creating a new lint group for rustdoc-specific lints; since we're planning on adding more over time, that would be a good way to handle them in a blanket fashion. cc @GuillaumeGomez

@kpp
Copy link
Contributor Author

kpp commented Sep 18, 2018

#![allow(intra_doc_link_resolution_failure)] worked for me!

@GuillaumeGomez
Copy link
Member

@QuietMisdreavus there is one, kind of. Nothing official yet though. :)

@QuietMisdreavus QuietMisdreavus added the A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. label Nov 6, 2018
@QuietMisdreavus
Copy link
Member

I've opened #56689 to add a new lint group for lints emitted by rustdoc.

@jyn514
Copy link
Member

jyn514 commented Apr 8, 2021

This was fixed by #56689; you can now use #[allow(rustdoc)] or #[allow(rustdoc::all)] to ignore rustdoc warnings (the attributes do the same thing, but the second only works on 1.52 and later).

@jyn514 jyn514 closed this as completed Apr 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants