Add listing of lints (eg via -W help) to rustdoc - #83895
Conversation
|
Looks like CI is stuck, but r=me when it's working. |
This comment has been minimized.
This comment has been minimized.
dc3f11f to
ad86be4
Compare
This comment has been minimized.
This comment has been minimized.
2cb42ba to
f805937
Compare
This comment has been minimized.
This comment has been minimized.
|
@bors r+ This is awesome, thank you! Nice job on normalizing the lint names :) |
|
📌 Commit 4d23c8e has been approved by |
|
Hmm, won't it be confusing since a lot of rustc lints won't be run by rustdoc? E.g., fn main() {
[1, 2, 3].into_iter();
}with |
|
@camelid you can still enable those lints with I think the list of lints enabled by default is separate, maybe we could just document that somewhere. |
Also, this is an implementation detail of how https://doc.rust-lang.org/nightly/rustdoc/advanced-features.html#cfgdoc-documenting-platform-specific-or-feature-specific-information works, it's not guarenteed. |
Rollup of 7 pull requests Successful merges: - rust-lang#82963 (Move `SharedContext` to `context.rs`) - rust-lang#83829 (rustc_target: Rely on defaults more in target specs) - rust-lang#83895 (Add listing of lints (eg via `-W help`) to rustdoc) - rust-lang#83902 (Update LLVM to support more wasm simd ops) - rust-lang#83903 (Fix typo in TokenStream documentation) - rust-lang#83910 (Update cargo) - rust-lang#83920 (Fix HashMap/HashSet LLDB pretty-printer after hashbrown 0.11.0) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Yes, but I think it could be confusing that |
That's separate from this change though, I don't think it should block it. |
rustdoc: add `--print` option Context: `--print crate-root-lint-levels` (rust-lang#139180) is only available for `rustc` and `clippy-driver`, while it would make sense for it to also be available for `rustdoc` (à la rust-lang#83895.) Not too sure about the stability of `rustdoc --print=any` or if this needs a MCP; strictly speaking, only `rustdoc +nightly -Z unstable-options --print=crate-root-lint-levels` would be required (and the `rustdoc --print` would be stabilized together with `crate-root-lint-levels`), but I guess that makes sense to have all the `--print`s for consistency. For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between `rustc()` and `rustdoc()` (or just test `rustdoc` as it delegates to `rustc`): https://github.com/rust-lang/rust/blob/021fc25b7a48f6051bee1e1f06c7a277e4de1cc9/tests/run-make/print-crate-root-lint-levels/rmake.rs#L82-L88 @rustbot label +A-CLI +A-print-requests
rustdoc: add `--print` option Context: `--print crate-root-lint-levels` (rust-lang#139180) is only available for `rustc` and `clippy-driver`, while it would make sense for it to also be available for `rustdoc` (à la rust-lang#83895.) Not too sure about the stability of `rustdoc --print=any` or if this needs a MCP; strictly speaking, only `rustdoc +nightly -Z unstable-options --print=crate-root-lint-levels` would be required (and the `rustdoc --print` would be stabilized together with `crate-root-lint-levels`), but I guess that makes sense to have all the `--print`s for consistency. For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between `rustc()` and `rustdoc()` (or just test `rustdoc` as it delegates to `rustc`): https://github.com/rust-lang/rust/blob/021fc25b7a48f6051bee1e1f06c7a277e4de1cc9/tests/run-make/print-crate-root-lint-levels/rmake.rs#L82-L88 @rustbot label +A-CLI +A-print-requests
rustdoc: add `--print` option Context: `--print crate-root-lint-levels` (rust-lang#139180) is only available for `rustc` and `clippy-driver`, while it would make sense for it to also be available for `rustdoc` (à la rust-lang#83895.) Not too sure about the stability of `rustdoc --print=any` or if this needs a MCP; strictly speaking, only `rustdoc +nightly -Z unstable-options --print=crate-root-lint-levels` would be required (and the `rustdoc --print` would be stabilized together with `crate-root-lint-levels`), but I guess that makes sense to have all the `--print`s for consistency. For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between `rustc()` and `rustdoc()` (or just test `rustdoc` as it delegates to `rustc`): https://github.com/rust-lang/rust/blob/021fc25b7a48f6051bee1e1f06c7a277e4de1cc9/tests/run-make/print-crate-root-lint-levels/rmake.rs#L82-L88 @rustbot label +A-CLI +A-print-requests
rustdoc: add `--print` option Context: `--print crate-root-lint-levels` (rust-lang#139180) is only available for `rustc` and `clippy-driver`, while it would make sense for it to also be available for `rustdoc` (à la rust-lang#83895.) Not too sure about the stability of `rustdoc --print=any` or if this needs a MCP; strictly speaking, only `rustdoc +nightly -Z unstable-options --print=crate-root-lint-levels` would be required (and the `rustdoc --print` would be stabilized together with `crate-root-lint-levels`), but I guess that makes sense to have all the `--print`s for consistency. For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between `rustc()` and `rustdoc()` (or just test `rustdoc` as it delegates to `rustc`): https://github.com/rust-lang/rust/blob/021fc25b7a48f6051bee1e1f06c7a277e4de1cc9/tests/run-make/print-crate-root-lint-levels/rmake.rs#L82-L88 @rustbot label +A-CLI +A-print-requests
Rollup merge of #151618 - ShE3py:rustdoc-print, r=notriddle rustdoc: add `--print` option Context: `--print crate-root-lint-levels` (#139180) is only available for `rustc` and `clippy-driver`, while it would make sense for it to also be available for `rustdoc` (à la #83895.) Not too sure about the stability of `rustdoc --print=any` or if this needs a MCP; strictly speaking, only `rustdoc +nightly -Z unstable-options --print=crate-root-lint-levels` would be required (and the `rustdoc --print` would be stabilized together with `crate-root-lint-levels`), but I guess that makes sense to have all the `--print`s for consistency. For regression tests, not sure if ui or run-make is preferable, as run-make would need some sort of trait to avoid duplicating code between `rustc()` and `rustdoc()` (or just test `rustdoc` as it delegates to `rustc`): https://github.com/rust-lang/rust/blob/021fc25b7a48f6051bee1e1f06c7a277e4de1cc9/tests/run-make/print-crate-root-lint-levels/rmake.rs#L82-L88 @rustbot label +A-CLI +A-print-requests
Fixes #83883
r? @jyn514