-
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: expose #[target_feature] attributes as doc(cfg) flags #48759
rustdoc: expose #[target_feature] attributes as doc(cfg) flags #48759
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
(btw, expect a PR to stdsimd to add some doc(cfg) so we can render as many arches as possible |
One matter this raises is that it uses the |
I think we should precise this is a target feature. Like this, if I didn't know I'd have no idea what id'd be about. |
☔ The latest upstream changes (presumably #48811) made this pull request unmergeable. Please resolve the merge conflicts. |
a643386
to
017bfc3
Compare
Fixed the merge conflict. @GuillaumeGomez I'm not sure i understand. Are you saying we should say "target feature" all the time? My assumption for abbreviating it on the module view was that you're already looking in |
When looking and the page, if I didn't know what this text was for, I'd be completely lost. Any kind of indication would help users a lot. |
And you can click through to see what it means. The "full version" is printed on the function's page. For configurations like |
Thanks! @bors: r+ |
📌 Commit b3fb0d1 has been approved by |
…r=GuillaumeGomez rustdoc: expose #[target_feature] attributes as doc(cfg) flags This change exposes `#[target_feature(enable = "feat")]` attributes on an item as if they were also `#[doc(cfg(target_feature = "feat"))]` attributes. This gives them a banner on their documentation listing which feature is required to use the item. It also modifies the rendering code for doc(cfg) tags to handle `target_feature` tags. I made it print just the feature name on "short" printings (as in the function listing on a module page), and use "target feature `feat`" in the full banner on the item page itself. This way, the function listing in `std::arch` shows which feature is required for each function: ![image](https://user-images.githubusercontent.com/5217170/37003222-f41b9d66-2091-11e8-9656-8719e5b34832.png) ![image](https://user-images.githubusercontent.com/5217170/37003234-feb1a7a2-2091-11e8-94de-6d1d76a2d3ee.png)
…ures, r=GuillaumeGomez add target features when extracting and running doctests When rendering documentation, rustdoc will happily load target features into the cfg environment from the current target, but fails to do this when doing anything with doctests. This would lead to situations where, thanks to rust-lang#48759, functions tagged with `#[target_feature]` couldn't run doctests, thanks to the automatic `#[doc(cfg(target_feature = "..."))]`. Currently, there's no way to pass codegen options to rustdoc that will affect its rustc sessions, but for now this will let you use target features that come default on the platform you're targeting. Fixes rust-lang#49723
This change exposes
#[target_feature(enable = "feat")]
attributes on an item as if they were also#[doc(cfg(target_feature = "feat"))]
attributes. This gives them a banner on their documentation listing which feature is required to use the item. It also modifies the rendering code for doc(cfg) tags to handletarget_feature
tags. I made it print just the feature name on "short" printings (as in the function listing on a module page), and use "target featurefeat
" in the full banner on the item page itself.This way, the function listing in
std::arch
shows which feature is required for each function: