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

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

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: A tracking issue for an RFC or an unstable feature. 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: A tracking issue for an RFC or an unstable feature. 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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