-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
rustdoc: replace most (e)println! statements with structured warnings/errors #50541
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
Fixing the merge conflict, just double-checking that it still builds before i finish the rebase. |
a6bd13d
to
e779481
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Oh nice, you improved my code quite a lot! Thanks a lot! @bors: r+ |
📌 Commit b7328e1 has been approved by |
⌛ Testing commit b7328e1b54a4f066e8202b655522528c4e830594 with merge 13a3971464f0503d2f2cc63aa6788147ee66717c... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1 similar comment
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors retry |
🔒 Merge conflict |
☔ The latest upstream changes (presumably #50235) made this pull request unmergeable. Please resolve the merge conflicts. |
b7328e1
to
c3fd12f
Compare
@bors r=GuillaumeGomez |
📌 Commit c3fd12f has been approved by |
…uillaumeGomez rustdoc: replace most (e)println! statements with structured warnings/errors Turns out, the rustc diagnostic handler doesn't need a whole lot of setup that we weren't already doing. For errors that occur outside a "dealing with source code" context, we can just use the format/color config we were already parsing and make up a `Handler` that we can emit structured warnings/errors from. So i did that. This will make it way easier to test things with `rustdoc-ui` tests, since those require the JSON error output. (In fact, this PR is a yak shave for a different one where i was trying to do just that. `>_>`)
rustdoc: replace most (e)println! statements with structured warnings/errors Turns out, the rustc diagnostic handler doesn't need a whole lot of setup that we weren't already doing. For errors that occur outside a "dealing with source code" context, we can just use the format/color config we were already parsing and make up a `Handler` that we can emit structured warnings/errors from. So i did that. This will make it way easier to test things with `rustdoc-ui` tests, since those require the JSON error output. (In fact, this PR is a yak shave for a different one where i was trying to do just that. `>_>`)
☀️ Test successful - status-appveyor, status-travis |
…=GuillaumeGomez rustdoc: deprecate `#![doc(passes, plugins, no_default_passes)]` Closes rust-lang#48164 Blocked on rust-lang#50541 - this includes those changes, which were necessary to create the UI test cc rust-lang#44136 Turns out, there were special attributes to mess with rustdoc passes and plugins! Who knew! Since we deprecated the CLI flags for this functionality, it makes sense that we do the same for the attributes. This PR also introduces a `#![doc(document_private_items)]` attribute, to match the `--document-private-items` flag introduced in rust-lang#44138 when the passes/plugins flags were deprecated. I haven't done a search to see whether these attributes are being used at all, but if the flags were any indication, i don't expect to see any users of these.
…eGomez Cleanup rustdoc warnings ## Clean up error reporting for deprecated passes Using `error!` here goes all the way back to the original commit, rust-lang#8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See rust-lang#81932 (comment) for further context. - Use spans for deprecated attributes - Use a proper diagnostic for unknown passes, instead of error logging - Add tests for unknown passes - Improve some wording in diagnostics ## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!` This also adds a test for the output. This was added in rust-lang#52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in rust-lang#50541.
…eGomez Cleanup rustdoc warnings ## Clean up error reporting for deprecated passes Using `error!` here goes all the way back to the original commit, rust-lang#8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See rust-lang#81932 (comment) for further context. - Use spans for deprecated attributes - Use a proper diagnostic for unknown passes, instead of error logging - Add tests for unknown passes - Improve some wording in diagnostics ## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!` This also adds a test for the output. This was added in rust-lang#52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in rust-lang#50541.
…eGomez Cleanup rustdoc warnings ## Clean up error reporting for deprecated passes Using `error!` here goes all the way back to the original commit, rust-lang#8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See rust-lang#81932 (comment) for further context. - Use spans for deprecated attributes - Use a proper diagnostic for unknown passes, instead of error logging - Add tests for unknown passes - Improve some wording in diagnostics ## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!` This also adds a test for the output. This was added in rust-lang#52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in rust-lang#50541.
…eGomez Cleanup rustdoc warnings ## Clean up error reporting for deprecated passes Using `error!` here goes all the way back to the original commit, rust-lang#8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See rust-lang#81932 (comment) for further context. - Use spans for deprecated attributes - Use a proper diagnostic for unknown passes, instead of error logging - Add tests for unknown passes - Improve some wording in diagnostics ## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!` This also adds a test for the output. This was added in rust-lang#52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in rust-lang#50541.
…eGomez Cleanup rustdoc warnings ## Clean up error reporting for deprecated passes Using `error!` here goes all the way back to the original commit, rust-lang#8540. I don't see any reason to use logging; rustdoc should use diagnostics wherever possible. See rust-lang#81932 (comment) for further context. - Use spans for deprecated attributes - Use a proper diagnostic for unknown passes, instead of error logging - Add tests for unknown passes - Improve some wording in diagnostics ## Report that `doc(plugins)` doesn't work using diagnostics instead of `eprintln!` This also adds a test for the output. This was added in rust-lang#52194. I don't see any particular reason not to use diagnostics here, I think it was just missed in rust-lang#50541.
Turns out, the rustc diagnostic handler doesn't need a whole lot of setup that we weren't already doing. For errors that occur outside a "dealing with source code" context, we can just use the format/color config we were already parsing and make up a
Handler
that we can emit structured warnings/errors from. So i did that. This will make it way easier to test things withrustdoc-ui
tests, since those require the JSON error output. (In fact, this PR is a yak shave for a different one where i was trying to do just that.>_>
)