-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Improve Rustdoc's handling of procedural macros #62855
Improve Rustdoc's handling of procedural macros #62855
Conversation
@Aaron1011 |
☔ The latest upstream changes (presumably #62086) made this pull request unmergeable. Please resolve the merge conflicts. |
fd5d16d
to
892b81f
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 |
Split off from rust-lang#62855 Currently, rustdoc ignores any doc comments found on 'pub use' statements. As described in issue rust-lang#58700, this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition, which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate, despite the fact that such items may be required to use the procedural macro. To solve this issue, this commit allows doc comments to be written on 'pub use' statements. For consistency, this applies to *all* 'pub use' statements, not just those importing procedural macros. When inlining documentation, documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example, the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is, this ensure that the doc comments on the definition start on a new line.
@petrochenkov: I've split the |
Note that due to changes in the metadata format, you should run |
☔ The latest upstream changes (presumably #63057) made this pull request unmergeable. Please resolve the merge conflicts. |
e2efa77
to
cbea48c
Compare
(@Aaron1011, if you have time, could you squash the commits to entirely remove traces of #63048 from this PR. I have a few busy days, but hope to return to this PR this week.) |
cc @eddyb, especially regarding the metadata bits. |
☔ The latest upstream changes (presumably #63234) made this pull request unmergeable. Please resolve the merge conflicts. |
cbea48c
to
ef755fc
Compare
…laumeGomez Use doc comments from 'pub use' statements Split off from #62855 Currently, rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700, this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition, which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate, despite the fact that such items may be required to use the procedural macro. To solve this issue, this commit allows doc comments to be written on 'pub use' statements. For consistency, this applies to *all* 'pub use' statements, not just those importing procedural macros. When inlining documentation, documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example, the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is, this ensure that the doc comments on the definition start on a new line.
Ok, let's do the next thing.
This is an important problem to solve and I'm glad someone is working on it, thanks. |
ef755fc
to
e38ddc4
Compare
Also, this PR should be |
Failed in #63864 (comment), @bors r- |
@bors retry |
…e-type proc-macro' Add a test to make sure that this works
@petrochenkov: As discussed in rust-lang/cargo#7159, I've modified this PR to support documenting proc-macro crates when This PR should now be ready to merge. |
@rustbot modify labels to +S-waiting-on-review, -S-waiting-on-bors |
@bors r+ |
📌 Commit 4c3e386 has been approved by |
…trochenkov Improve Rustdoc's handling of procedural macros Fixes #58700 Fixes #58696 Fixes #49553 Fixes #52210 This commit removes the special rustdoc handling for proc macros, as we can now retrieve their span and attributes just like any other item. A new command-line option is added to rustdoc: `--crate-type`. This takes the same options as rustc's `--crate-type` option. However, all values other than `proc-macro` are treated the same. This allows Rustdoc to enable 'proc macro mode' when handling a proc macro crate. In compiletest, a new 'rustdoc-flags' option is added. This allows us to pass in the '--proc-macro-crate' flag in the absence of Cargo. I've opened [an additional PR to Cargo](rust-lang/cargo#7159) to support passing in this flag. These two PRS can be merged in any order - the Cargo changes will not take effect until the 'cargo' submodule is updated in this repository.
☀️ Test successful - checks-azure |
Tested on commit rust-lang/rust@3476543. Direct link to PR: <rust-lang/rust#62855> 💔 rustc-guide on linux: test-pass → test-fail (cc @mark-i-m @spastorino @amanjeev, @rust-lang/infra).
…lexcrichton Pass --crate-type to rustdoc This supports the [corresponding rustc PR](rust-lang/rust#62855). To enable rustdoc to properly document macros, we pass a new flag '--proc-macro-crate' when documenting a proc-macro crate. This causes rustdoc to enable the proc-macro compiler logic that runs when rustc is building a proc-macro crate. This flag is essentially a more restricted version of '--crate-type=proc-macro'. I didn't think it was necessary to pass the full '--crate-type' flag to rustdoc, when only two options would ever be used (proc-macro vs anything else).
…=estebank [breaking change] Remove a rustdoc back compat warning This warning was introduced in rust-lang#62855 for users who use `rustdoc` directly on proc macro crates (instead of using `cargo doc`) without passing `--crate-type proc-macro` (which `cargo doc` passed automatically).
Fixes #58700
Fixes #58696
Fixes #49553
Fixes #52210
This commit removes the special rustdoc handling for proc macros, as we can now
retrieve their span and attributes just like any other item.
A new command-line option is added to rustdoc:
--crate-type
. This takes the same options as rustc's--crate-type
option. However, all values other thanproc-macro
are treated the same. This allows Rustdoc to enable 'proc macro mode' when handling a proc macro crate.In compiletest, a new 'rustdoc-flags' option is added. This allows us to
pass in the '--proc-macro-crate' flag in the absence of Cargo.
I've opened an additional PR to Cargo to support passing in this flag.
These two PRS can be merged in any order - the Cargo changes will not
take effect until the 'cargo' submodule is updated in this repository.