mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
67a835d755
rust/tests/rustdoc/doc-cfg.rs

102 lines
3.9 KiB
Rust
Raw Normal View History

Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
#![feature(doc_cfg)]
add target_feature items to doc_cfg rustdoc test
2018-03-21 19:57:10 -05:00
#![feature(target_feature, cfg_target_feature)]
Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
// @has doc_cfg/struct.Portable.html
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// @!has - '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' ''
Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
// @has - '//*[@id="method.unix_and_arm_only_function"]' 'fn unix_and_arm_only_function()'
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// @has - '//*[@class="stab portability"]' 'Available on Unix and ARM only.'
Add a test in src/test/rustdoc/doc-cfg.rs
2021-02-28 16:07:05 -06:00
// @has - '//*[@id="method.wasi_and_wasm32_only_function"]' 'fn wasi_and_wasm32_only_function()'
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// @has - '//*[@class="stab portability"]' 'Available on WASI and WebAssembly only.'
Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
pub struct Portable;
// @has doc_cfg/unix_only/index.html \
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available on Unix only.'
rustdoc: simplify DOM for `.item-table` This switches from using `<div>` to the more semantic `<ul>`, and using class names that rhyme with the classes the search results table uses.
2023-02-07 20:00:18 -06:00
// @matches - '//*[@class="item-name"]//*[@class="stab portability"]' '\AARM\Z'
Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page, but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering, as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first.
2020-10-06 13:48:01 -05:00
// @count - '//*[@class="stab portability"]' 2
Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
#[doc(cfg(unix))]
pub mod unix_only {
// @has doc_cfg/unix_only/fn.unix_only_function.html \
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available on Unix only.'
Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
// @count - '//*[@class="stab portability"]' 1
pub fn unix_only_function() {
content::should::be::irrelevant();
}
// @has doc_cfg/unix_only/trait.ArmOnly.html \
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available on Unix and ARM only.'
Apply `doc(cfg)` from parent items while collecting trait impls Because trait impls bypass the standard `clean` hierarchy they do not participate in the `propagate_doc_cfg` pass, so instead we need to pre-collect all possible `doc(cfg)` attributes that will apply to them when cleaning.
2020-11-23 06:22:56 -06:00
// @count - '//*[@class="stab portability"]' 1
Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
#[doc(cfg(target_arch = "arm"))]
pub trait ArmOnly {
fn unix_and_arm_only_function();
}
Apply `doc(cfg)` from parent items while collecting trait impls Because trait impls bypass the standard `clean` hierarchy they do not participate in the `propagate_doc_cfg` pass, so instead we need to pre-collect all possible `doc(cfg)` attributes that will apply to them when cleaning.
2020-11-23 06:22:56 -06:00
#[doc(cfg(target_arch = "arm"))]
Implemented #[doc(cfg(...))]. This attribute has two effects: 1. Items with this attribute and their children will have the "This is supported on **** only" message attached in the documentation. 2. The items' doc tests will be skipped if the configuration does not match.
2017-08-05 01:38:52 -05:00
impl ArmOnly for super::Portable {
fn unix_and_arm_only_function() {}
}
Add trailing newlines to files which have no trailing newlines.
2017-12-29 12:25:40 -06:00
}
add target_feature items to doc_cfg rustdoc test
2018-03-21 19:57:10 -05:00
Add a test in src/test/rustdoc/doc-cfg.rs
2021-02-28 16:07:05 -06:00
// @has doc_cfg/wasi_only/index.html \
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available on WASI only.'
rustdoc: simplify DOM for `.item-table` This switches from using `<div>` to the more semantic `<ul>`, and using class names that rhyme with the classes the search results table uses.
2023-02-07 20:00:18 -06:00
// @matches - '//*[@class="item-name"]//*[@class="stab portability"]' '\AWebAssembly\Z'
Add a test in src/test/rustdoc/doc-cfg.rs
2021-02-28 16:07:05 -06:00
// @count - '//*[@class="stab portability"]' 2
#[doc(cfg(target_os = "wasi"))]
pub mod wasi_only {
// @has doc_cfg/wasi_only/fn.wasi_only_function.html \
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available on WASI only.'
Add a test in src/test/rustdoc/doc-cfg.rs
2021-02-28 16:07:05 -06:00
// @count - '//*[@class="stab portability"]' 1
pub fn wasi_only_function() {
content::should::be::irrelevant();
}
// @has doc_cfg/wasi_only/trait.Wasm32Only.html \
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available on WASI and WebAssembly only.'
Add a test in src/test/rustdoc/doc-cfg.rs
2021-02-28 16:07:05 -06:00
// @count - '//*[@class="stab portability"]' 1
#[doc(cfg(target_arch = "wasm32"))]
pub trait Wasm32Only {
fn wasi_and_wasm32_only_function();
}
#[doc(cfg(target_arch = "wasm32"))]
impl Wasm32Only for super::Portable {
fn wasi_and_wasm32_only_function() {}
}
}
add target_feature items to doc_cfg rustdoc test
2018-03-21 19:57:10 -05:00
// tagging a function with `#[target_feature]` creates a doc(cfg(target_feature)) node for that
// item as well
// the portability header is different on the module view versus the full view
// @has doc_cfg/index.html
rustdoc: simplify DOM for `.item-table` This switches from using `<div>` to the more semantic `<ul>`, and using class names that rhyme with the classes the search results table uses.
2023-02-07 20:00:18 -06:00
// @matches - '//*[@class="item-name"]//*[@class="stab portability"]' '\Aavx\Z'
add target_feature items to doc_cfg rustdoc test
2018-03-21 19:57:10 -05:00
// @has doc_cfg/fn.uses_target_feature.html
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// @has - '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available with target feature avx only.'
add target_feature items to doc_cfg rustdoc test
2018-03-21 19:57:10 -05:00
#[target_feature(enable = "avx")]
pub unsafe fn uses_target_feature() {
content::should::be::irrelevant();
}
// @has doc_cfg/fn.uses_cfg_target_feature.html
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// @has - '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available with target feature avx only.'
add target_feature items to doc_cfg rustdoc test
2018-03-21 19:57:10 -05:00
#[doc(cfg(target_feature = "avx"))]
pub fn uses_cfg_target_feature() {
uses_target_feature();
}
Unify rustc and rustdoc parsing of `cfg()` This extracts a new `parse_cfg` function that's used between both. - Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)] #[doc(cfg(y))]`. Previously it would be completely ignored. - Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)] #[doc(cfg(x))]`. Previously, the cfg would be ignored. - Pass the cfg predicate through to rustc_expand to be validated Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2021-04-22 12:28:43 -05:00
// multiple attributes should be allowed
// @has doc_cfg/fn.multiple_attrs.html \
Rename ID "main" into "main-content"
2021-11-29 10:14:05 -06:00
// '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]' \
clarify doc(cfg) wording The current "This is supported" wording implies that it's possible to still use the item on other configurations, but in an unsupported way. Changing this to "Available" removes this ambiguity.
2022-04-14 18:03:56 -05:00
// 'Available on x and y and z only.'
Fix warnings in rustdoc HTML tests Now that compiletest denies warnings in these tests, they need fixing!
2021-11-26 17:03:16 -06:00
#[doc(cfg(x))]
Unify rustc and rustdoc parsing of `cfg()` This extracts a new `parse_cfg` function that's used between both. - Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)] #[doc(cfg(y))]`. Previously it would be completely ignored. - Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)] #[doc(cfg(x))]`. Previously, the cfg would be ignored. - Pass the cfg predicate through to rustc_expand to be validated Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2021-04-22 12:28:43 -05:00
#[doc(cfg(y), cfg(z))]
pub fn multiple_attrs() {}
Reference in New Issue Copy Permalink