Skip to content

Tracking issue for #[doc(keyword = "...")] #51315

New issue

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

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

Already on GitHub? # to your account

Open
GuillaumeGomez opened this issue Jun 2, 2018 · 13 comments
Open

Tracking issue for #[doc(keyword = "...")] #51315

GuillaumeGomez opened this issue Jun 2, 2018 · 13 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC S-tracking-perma-unstable Status: The feature will stay unstable indefinitely. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@GuillaumeGomez
Copy link
Member

Implemented in #51140.

@estebank estebank added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC and removed A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools labels Jan 8, 2019
@jonas-schievink jonas-schievink added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Nov 26, 2019
@jyn514
Copy link
Member

jyn514 commented Nov 4, 2020

Does this actually need to be stabilized? Even #[no_core] isn't stable and doc(keyword) is pretty useless unless you're core.

@GuillaumeGomez
Copy link
Member Author

It could be very useful for proc-macros. :)

@jyn514
Copy link
Member

jyn514 commented Nov 4, 2020

cc @danielhenrymantilla - do you know if this works/is useful for proc-macros?

@danielhenrymantilla
Copy link
Contributor

The fact that:

#[cfg(any())]
#[doc(keyword = "foo")]
mod foo {}

already compiles fine means that a proc-macro can be put instead of #[cfg(any())] and if it strips the #[doc(keyword = …)] from the emitted code, it will not get into trouble. So if proc-macros wanted to use #[doc(keyword = …)] as extra input to it (I personally find it a bit odd, but I may very well lack the imagination for a motivating use-case 🤷 ), then they currently already can.


lack the imagination

Ok, I have had some enlightenment all of a sudden, and I may know what @GuillaumeGomez meant by that: it would be a way to "document" special keywords a macro may take, either as direct params of a proc_macro_attribute, or as special helper / inert attributes of a #[proc_macro_derive)]:

Screenshot 2020-11-04 at 13 57 53

Screenshot 2020-11-04 at 13 58 50

That can be an actually very nice use case, but, in this case, using the mechanics to document a language keyword for custom proc-macros keywords is a bit hacky, and it does impact the resulting ergonomics of it:

  1. First and foremost, the current implementation of it forbids using any keyword that isn't really one (aside: warning when it's not the case would be a good thing, I was a bit confused when I tried it myself with recursive and nothing was showing up 😅 ; I ended up providing something like unsafe for it to work).

    • Documenting the unsafe keyword, however, could be a very interesting thing to do, so as to put the higher-level safety contracts of your crate in that section 🤔
  • it currently cannot be rendered as a sub-item of the attached proc-macro, so it doesn't "look that nice".

@GuillaumeGomez
Copy link
Member Author

Ok, I have had some enlightenment all of a sudden, and I may know what @GuillaumeGomez meant by that: it would be a way to "document" special keywords a macro may take, either as direct params of a proc_macro_attribute, or as special helper / inert attributes of a #[proc_macro_derive)]:

Exactly! Sorry, I should have precised my words. :)

@pickfire
Copy link
Contributor

I can't seemed to get this working.

#[doc(keyword = "hello")]
/// Hello world
mod hello {} 

Also, what happens if there is no mod? Will the doc just silently disappear?

@GuillaumeGomez
Copy link
Member Author

@pickfire I didn't understand your comment. The best I can recommend you is to look at how we use it in the std library, maybe that will answer your questions. :)

@pickfire
Copy link
Contributor

pickfire commented Nov 25, 2020

I did look at how it is used in standard library. The code I show above is in src/lib.rs (with the feature) and I ran cargo doc but the keywords section doesn't seemed to be there.

@GuillaumeGomez
Copy link
Member Author

Needless to say it's surprising considering that it works perfectly for the std right? 😆

You maybe just missed something? But normally, you just need to enable the feature and then to add #[doc(keyword = "...")] on an empty module...

@danielhenrymantilla
Copy link
Contributor

@pickfire

the current implementation of it forbids using any keyword that isn't really one (aside: warning when it's not the case would be a good thing, I was a bit confused when I tried it myself with recursive and nothing was showing up 😅

Have you tried using #[doc(keyword = "unsafe")], for instance? The current list of valid keywords is hard-coded, and when you provide an extraneous one / one that doesn't belong to that list, it silently ignores / discards the attribute / the directive:

https://github.com/GuillaumeGomez/rust/blob/2f7fa24aee7f7e69f9fbc37e8d2084fb1c898e97/src/librustdoc/clean/mod.rs#L309-L316

@GuillaumeGomez
Copy link
Member Author

@danielhenrymantilla Completely forgot about that one... Good catch, thanks a lot!

@pickfire
Copy link
Contributor

Have you tried using #[doc(keyword = "unsafe")], for instance? The current list of valid keywords is hard-coded, and when you provide an extraneous one / one that doesn't belong to that list, it silently ignores / discards the attribute / the directive:

Thanks for showing that. I didn't know it uses only hard-coded keywords, maybe rust should give an error when using invalid keywords? At least that won't confuse other users.

@GuillaumeGomez
Copy link
Member Author

I think it should allow all keywords. The goal being to be able to document macro specific keywords in the end...

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Nov 28, 2020
…=jyn514

Extend doc keyword feature by allowing any ident

Part of rust-lang#51315.

As suggested by `@danielhenrymantilla` in [this comment](rust-lang#51315 (comment)), this PR extends `#[doc(keyword = "...")]` to allow any ident to be used as keyword. The final goal is to allow (proc-)macro crates' owners to write documentation of the keywords they might introduce.

r? `@jyn514`
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Nov 29, 2020
…=jyn514

Extend doc keyword feature by allowing any ident

Part of rust-lang#51315.

As suggested by ``@danielhenrymantilla`` in [this comment](rust-lang#51315 (comment)), this PR extends `#[doc(keyword = "...")]` to allow any ident to be used as keyword. The final goal is to allow (proc-)macro crates' owners to write documentation of the keywords they might introduce.

r? ``@jyn514``
github-actions bot pushed a commit to rust-lang/glacier that referenced this issue Jun 19, 2021
=== stdout ===
=== stderr ===
error[E0658]: `#[doc(keyword)]` is experimental
 --> /home/runner/work/glacier/glacier/ices/83512.rs:2:5
  |
2 |     #[doc(keyword = "match")]
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #51315 <rust-lang/rust#51315> for more information
  = help: add `#![feature(doc_keyword)]` to the crate attributes to enable

error[E0601]: `main` function not found in crate `83512`
 --> /home/runner/work/glacier/glacier/ices/83512.rs:1:1
  |
1 | / trait Foo {
2 | |     #[doc(keyword = "match")]
3 | |     fn quux() {}
4 | | }
  | |_^ consider adding a `main` function to `/home/runner/work/glacier/glacier/ices/83512.rs`

error: `#[doc(keyword = "...")]` can only be used on modules
 --> /home/runner/work/glacier/glacier/ices/83512.rs:2:11
  |
2 |     #[doc(keyword = "match")]
  |           ^^^^^^^^^^^^^^^^^

error: aborting due to 3 previous errors

Some errors have detailed explanations: E0601, E0658.
For more information about an error, try `rustc --explain E0601`.
==============
@Dylan-DPC Dylan-DPC added the S-tracking-perma-unstable Status: The feature will stay unstable indefinitely. label Feb 23, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC S-tracking-perma-unstable Status: The feature will stay unstable indefinitely. 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

7 participants