Tracking Issue for RFC 3013: Checking conditional compilation at compile time #82450

ehuss · 2021-02-23T18:08:13Z

This is a tracking issue for the RFC 3013: Checking conditional compilation at compile time (rust-lang/rfcs#3013).

Issues: F-check-cfg --check-cfg
Documentation: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
Adjust documentation (check_cfg - Unstable book)
Stabilization PR (FCP: Tracking Issue for RFC 3013: Checking conditional compilation at compile time #82450 (comment))

Unresolved Questions

Which cfgs should be implicitly included? See this list in bootstrap for an example of some values that need "adding in" atop compiler defaults. (Try to go to master in the link above; the list may have been updated since then).

Implementation history

cc rust-lang#82450

Implement --check-cfg option (RFC 3013), take 2 This pull-request implement RFC 3013: Checking conditional compilation at compile time (rust-lang/rfcs#3013) and is based on the previous attempt rust-lang#89346 by `@mwkmwkmwk` that was closed due to inactivity. I have address all the review comments from the previous attempt and added some more tests. cc rust-lang#82450 r? `@petrochenkov`

Urgau · 2022-02-21T12:20:21Z

The implementation of this RFC has been merged in rustc as unstable and is already in nightly for experimentation. 🎉

The next the steps for the rustc side will be to improve it with suggestions, auto-fix in obvious cases and hopefully add well known values (non-builtin target is a problem), the rfc doesn't mention it directly but this seems pretty obvious. Some of this stuff is already tackle by #94175.

We almost certainly want rustdoc to also have it (because rustc doesn't know about doc tests and rustdoc also have --cfg so it seems good to be consistent), so I've opened #94154 to tackle it.

And last but not least the cargo integration, the RFC intentionally left the control part out of the RFC, but I have some ideas about how it could be done. But as RFC said it seems uncontroversial for Cargo to enable checking for feature = "..." values, so I'm currently tackling this part. ~~No PR for this yet, but I'm working on it.~~

EDIT: Cargo PR rust-lang/cargo#10408, merged ~~but not yet in nightly~~ see #82450 (comment)

jhpratt · 2022-02-21T19:57:55Z

Wow, that's awesome! I didn't even know this was being worked on actively.

As someone who would like love to use this in CI, how feasible is it to try this on nightly, even if "just" for features? I ask because it sounds like cargo integration isn't a thing yet.

Urgau · 2022-02-21T20:37:05Z

Wow, that's awesome! I didn't even know this was being worked on actively.

❤️

As someone who would like love to use this in CI, how feasible is it to try this on nightly, even if "just" for features? I ask because it sounds like cargo integration isn't a thing yet.

It would just be a matter of passing something like this -Z unstable-options --check-cfg='values(feature, "f_a", "f_b", "f_n")' where f_a, f_b, ... f_n are your features name to rustc with cargo you can use the RUSTFLAGS env variable do to it. This manual process is only temporary until cargo support is added.

RUSTFLAGS='-Z unstable-options --check-cfg=values(feature,"f_a","f_b","f_n")' cargo build

jhpratt · 2022-02-21T20:41:33Z

That's not bad at all! I'll definitely add in a CI check.

Urgau · 2022-02-26T12:03:52Z

Good news! rustdoc (#94154) and cargo (only features, rust-lang/cargo#10408) support have been merged. 🎆 As well a some improvements to the lint (#94175).

You can now simply use cargo build -Z check-cfg-fetaures to check values of every config feature. Works with: check, build and test.

$ cargo +nightly check -Z check-cfg-features

    Checking hoho v0.1.0 (/tmp/hoho)
warning: unexpected `cfg` condition value
 --> src/main.rs:1:7
  |
1 | #[cfg(feature = "tokiO")]
  |       ^^^^^^^^^^-------
  |                 |
  |                 help: did you mean (notice the capitalization): `"tokio"`
  |
  = note: `#[warn(unexpected_cfgs)]` on by default
  = note: expected values for `feature` are: default, serde, tokio

warning: `hoho` (bin "hoho") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.54s

c410-f3r · 2022-02-26T16:24:45Z

Thank you for all the hard work, @Urgau

petrochenkov · 2022-03-21T14:47:13Z

Enabling --check-cfg=values() currently incurs some compilation time hit (especially on small programs) because it will load target specifications for all targets (100-200 of them at the moment), while without --check-cfg=values() targets are only loaded on demand (so only 1-2 target specs are typically loaded).

In theory, majority of targets can be loaded at compiler's compile time instead (and put into a static).
In that case only a few Apple targets will be loaded dynamically because they need to read environment variables from the host.
The main blocker for this is supporting String::from("foo") at compile time (i.e. const allocations).

petrochenkov · 2022-03-21T14:48:02Z

Enabling --check-cfg=values() currently incurs some compilation time hit (especially on small programs)

Someone also needs to prepare a perf run to measure the exact slowdown.

lcnr · 2022-03-21T14:58:53Z

The main blocker for this is supporting String::from("foo") at compile time (i.e. const allocations).

Alternatively one could use some Cow or whatever for targets instead of String.

This is the next upgrade to the Rust toolchain, from 1.76.0 to 1.77.0 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2"). The `offset_of` feature (single-field `offset_of!`) that we were using got stabilized in Rust 1.77.0 [3]. Therefore, now the only unstable features allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [4] for details. Rust 1.77.0 merged the `unused_tuple_struct_fields` lint into `dead_code`, thus upgrading it from `allow` to `warn` [5]. In turn, this makes `rustc` complain about the `ThisModule`'s pointer field being never read. Thus locally `allow` it for the moment, since we will have users later on (e.g. Binder needs a `as_ptr` method [6]). Rust 1.77.0 introduces the `--check-cfg` feature [7], for which there is a Call for Testing going on [8]. We were requested to test it and we found it useful [9] -- we will likely enable it in the future. The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1770-2024-03-21 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: rust-lang/rust#118799 [3] Link: #2 [4] Link: rust-lang/rust#118297 [5] Link: https://lore.kernel.org/rust-for-linux/[email protected]/#Z31rust:kernel:lib.rs [6] Link: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html [7] Link: rust-lang/rfcs#3013 (comment) [8] Link: rust-lang/rust#82450 (comment) [9] Signed-off-by: Miguel Ojeda <[email protected]> Link: https://lore.kernel.org/r/[email protected]

This is the next upgrade to the Rust toolchain, from 1.76.0 to 1.77.0 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2"). The `offset_of` feature (single-field `offset_of!`) that we were using got stabilized in Rust 1.77.0 [3]. Therefore, now the only unstable features allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [4] for details. Rust 1.77.0 merged the `unused_tuple_struct_fields` lint into `dead_code`, thus upgrading it from `allow` to `warn` [5]. In turn, this makes `rustc` complain about the `ThisModule`'s pointer field being never read. Thus locally `allow` it for the moment, since we will have users later on (e.g. Binder needs a `as_ptr` method [6]). Rust 1.77.0 introduces the `--check-cfg` feature [7], for which there is a Call for Testing going on [8]. We were requested to test it and we found it useful [9] -- we will likely enable it in the future. The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1770-2024-03-21 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: rust-lang/rust#118799 [3] Link: #2 [4] Link: rust-lang/rust#118297 [5] Link: https://lore.kernel.org/rust-for-linux/[email protected]/#Z31rust:kernel:lib.rs [6] Link: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html [7] Link: rust-lang/rfcs#3013 (comment) [8] Link: rust-lang/rust#82450 (comment) [9] Signed-off-by: Miguel Ojeda <[email protected]> Link: https://lore.kernel.org/r/[email protected] [boqun: Resolve the conflicts with using upstream alloc]

This is the next upgrade to the Rust toolchain, from 1.76.0 to 1.77.1 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2"). # Unstable features The `offset_of` feature (single-field `offset_of!`) that we were using got stabilized in Rust 1.77.0 [3]. Therefore, now the only unstable features allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [4] for details. # Required changes Rust 1.77.0 merged the `unused_tuple_struct_fields` lint into `dead_code`, thus upgrading it from `allow` to `warn` [5]. In turn, this made `rustc` complain about the `ThisModule`'s pointer field being never read, but the previous patch adds the `as_ptr` method to it, needed by Binder [6], so that we do not need to locally `allow` it. # Other changes Rust 1.77.0 introduces the `--check-cfg` feature [7], for which there is a Call for Testing going on [8]. We were requested to test it and we found it useful [9] -- we will likely enable it in the future. # `alloc` upgrade and reviewing The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1770-2024-03-21 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: rust-lang/rust#118799 [3] Link: Rust-for-Linux#2 [4] Link: rust-lang/rust#118297 [5] Link: https://lore.kernel.org/rust-for-linux/[email protected]/#Z31rust:kernel:lib.rs [6] Link: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html [7] Link: rust-lang/rfcs#3013 (comment) [8] Link: rust-lang/rust#82450 (comment) [9] Reviewed-by: Alice Ryhl <[email protected]> Tested-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Upgraded to 1.77.1. No changed to `alloc` during the beta. ] Signed-off-by: Miguel Ojeda <[email protected]>

This is the next upgrade to the Rust toolchain, from 1.76.0 to 1.77.1 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2"). # Unstable features The `offset_of` feature (single-field `offset_of!`) that we were using got stabilized in Rust 1.77.0 [3]. Therefore, now the only unstable features allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [4] for details. # Required changes Rust 1.77.0 merged the `unused_tuple_struct_fields` lint into `dead_code`, thus upgrading it from `allow` to `warn` [5]. In turn, this made `rustc` complain about the `ThisModule`'s pointer field being never read, but the previous patch adds the `as_ptr` method to it, needed by Binder [6], so that we do not need to locally `allow` it. # Other changes Rust 1.77.0 introduces the `--check-cfg` feature [7], for which there is a Call for Testing going on [8]. We were requested to test it and we found it useful [9] -- we will likely enable it in the future. # `alloc` upgrade and reviewing The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1770-2024-03-21 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: rust-lang/rust#118799 [3] Link: #2 [4] Link: rust-lang/rust#118297 [5] Link: https://lore.kernel.org/rust-for-linux/[email protected]/#Z31rust:kernel:lib.rs [6] Link: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html [7] Link: rust-lang/rfcs#3013 (comment) [8] Link: rust-lang/rust#82450 (comment) [9] Reviewed-by: Alice Ryhl <[email protected]> Tested-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Upgraded to 1.77.1. Removed `allow(dead_code)` thanks to the previous patch. Reworded accordingly. No changes to `alloc` during the beta. ] Signed-off-by: Miguel Ojeda <[email protected]>

This is the next upgrade to the Rust toolchain, from 1.76.0 to 1.77.1 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2"). # Unstable features The `offset_of` feature (single-field `offset_of!`) that we were using got stabilized in Rust 1.77.0 [3]. Therefore, now the only unstable features allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [4] for details. # Required changes Rust 1.77.0 merged the `unused_tuple_struct_fields` lint into `dead_code`, thus upgrading it from `allow` to `warn` [5]. In turn, this made `rustc` complain about the `ThisModule`'s pointer field being never read, but the previous patch adds the `as_ptr` method to it, needed by Binder [6], so that we do not need to locally `allow` it. # Other changes Rust 1.77.0 introduces the `--check-cfg` feature [7], for which there is a Call for Testing going on [8]. We were requested to test it and we found it useful [9] -- we will likely enable it in the future. # `alloc` upgrade and reviewing The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1770-2024-03-21 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: rust-lang/rust#118799 [3] Link: Rust-for-Linux#2 [4] Link: rust-lang/rust#118297 [5] Link: https://lore.kernel.org/rust-for-linux/[email protected]/#Z31rust:kernel:lib.rs [6] Link: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html [7] Link: rust-lang/rfcs#3013 (comment) [8] Link: rust-lang/rust#82450 (comment) [9] Reviewed-by: Alice Ryhl <[email protected]> Tested-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Upgraded to 1.77.1. Removed `allow(dead_code)` thanks to the previous patch. Reworded accordingly. No changes to `alloc` during the beta. ] Signed-off-by: Miguel Ojeda <[email protected]>

rfcbot · 2024-04-05T01:43:24Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2024-04-15T01:45:21Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

…chenkov Stabilize checking of cfgs at compile-time: `--check-cfg` option This PR stabilize the `--check-cfg` CLI option of `rustc` (and `rustdoc`) 🎉. In particular this PR does two things: 1. it makes the `--check-cfg` option stable 2. and it moves the documentation to the stable books FCP: rust-lang#82450 (comment) Resolves rust-lang#82450 `@rustbot` labels +S-blocked +F-check-cfg r? `@petrochenkov`

Rollup merge of rust-lang#123501 - Urgau:stabilize-check-cfg, r=petrochenkov Stabilize checking of cfgs at compile-time: `--check-cfg` option This PR stabilize the `--check-cfg` CLI option of `rustc` (and `rustdoc`) 🎉. In particular this PR does two things: 1. it makes the `--check-cfg` option stable 2. and it moves the documentation to the stable books FCP: rust-lang#82450 (comment) Resolves rust-lang#82450 ``@rustbot`` labels +S-blocked +F-check-cfg r? ``@petrochenkov``

Stabilize `-Zcheck-cfg` as always enabled This PR stabilize the `-Zcheck-cfg` option as always enabled. ~~Waiting on rust-lang/rust#82450 (comment) to complete, but is otherwise ready to be reviewed (in particular the documentation changes).~~ (rust-lang/rust#123501) Fixes #10554

ref: rust-lang/rust#82450 there will probably be a cleaner fix at some point (or even a change in how the nightly cfg is implemented)

* fix: add a temporary exception for a new lint ref: rust-lang/rust#82450 there will probably be a cleaner fix at some point (or even a change in how the nightly cfg is implemented) * fix: update a broken link in doc

rustc 1.80 now complains about features not declared in Cargo.toml and cfg keys/values not declared by build.rs to protect against typos or misuse (you think you're using the right condition but you're not). See rust-lang/cargo#10554 and rust-lang/rust#82450. (We're not actually using TSAN under CI at this time, but I do want to re-enable it at some point — especially if we get multithreaded execution going — using the rust-native TSAN configuration.) I'll be updating the `rsconf` crate and patching `build.rs` accordingly to also handle the warnings about unknown cfg values, but tsan is a feature and not a cfg and these can be dealt with in `Cargo.toml` directly.

Recently nightly `rustc` enabled `unexpected_cfgs` lint by default. Since this project uses non-standard cfg names, they started to cause warnings like below on Linux: ``` warning: unexpected `cfg` condition name: `gtk` --> src/lib.rs:1029:17 | 1029 | #[cfg(not(gtk))] | ^^^ | = help: consider using a Cargo feature instead = help: or consider adding in `Cargo.toml` the `check-cfg` lint config for the lint: [lints.rust] unexpected_cfgs = { level = "warn", check-cfg = ['cfg(gtk)'] } = help: or consider adding `println!("cargo::rustc-check-cfg=cfg(gtk)");` to the top of the `build.rs` = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration ``` Ref: rust-lang/rust#82450 Signed-off-by: rhysd <[email protected]>

ehuss added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Feb 23, 2021

ehuss mentioned this issue Feb 23, 2021

RFC: Checking conditional compilation at compile time rust-lang/rfcs#3013

Merged

wesleywiser added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Jun 2, 2021

ehuss mentioned this issue Jul 6, 2021

Check for missing features in Cargo.toml rust-lang/cargo#8070

Closed

mwkmwkmwk added a commit to mwkmwkmwk/rust that referenced this issue Sep 29, 2021

Implement --check-cfg option (RFC 3013)

49897f1

cc rust-lang#82450

mwkmwkmwk mentioned this issue Sep 29, 2021

Implement --check-cfg option (RFC 3013) #89346

Closed

3 tasks

ehuss mentioned this issue Nov 19, 2021

papercut: cargo does not provide feedback when using a cfg(feature = "...") that is not declared in Cargo.toml rust-lang/cargo#10102

Closed

flip1995 mentioned this issue Jan 13, 2022

Expand mismatched_target_os lint to check macro position usage rust-lang/rust-clippy#8192

Closed

bjorn3 mentioned this issue Feb 8, 2022

Add undefined feature diagnostic rust-lang/rust-analyzer#11435

Open

jplatte mentioned this issue Feb 8, 2022

Lint references to features not defined in Cargo.toml rust-lang/rust-clippy#1614

Closed

ShadowJonathan mentioned this issue Feb 8, 2022

Integrate "MSC feature tracking" in xtask ruma/ruma#867

Open

3 tasks

Urgau mentioned this issue Feb 11, 2022

Implement --check-cfg option (RFC 3013), take 2 #93915

Merged

est31 mentioned this issue Feb 20, 2022

Lints for target_* cfg #85753

Closed

Urgau mentioned this issue Mar 22, 2022

Reduce the cost of loading all built-ins targets #95202

Merged

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Apr 5, 2024

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Apr 5, 2024

y21 mentioned this issue Apr 5, 2024

Detect cfg based on an undeclared feature rust-lang/rust-clippy#12634

Closed

Urgau mentioned this issue Apr 5, 2024

Stabilize checking of cfgs at compile-time: --check-cfg option #123501

Merged

bors closed this as completed in f54219c Apr 16, 2024

apiraino removed the to-announce Announce this issue on triage meeting label May 3, 2024

imrn99 added a commit to LIHPC-Computational-Geometry/honeycomb that referenced this issue May 6, 2024

fix: add a temporary exception for a new lint

b986487

ref: rust-lang/rust#82450 there will probably be a cleaner fix at some point (or even a change in how the nightly cfg is implemented)

Urgau mentioned this issue May 6, 2024

Add fuzzing and loom to well-known cfgs #124804

Closed

wesleywiser mentioned this issue May 7, 2024

New rustc nightly suggests adding a build.rs to use conditional compilation #124800

Closed

pnkfelix mentioned this issue May 7, 2024

#![allow(unexpected_cfgs)] does not work for modules #124735

Open

rhysd mentioned this issue May 30, 2024

fix(linux): fix warnings from unexpected_cfgs lint on nightly tauri-apps/wry#1280

Merged

rhysd mentioned this issue Jun 16, 2024

fix: fix warnings reported from nightly rustc pulldown-cmark/pulldown-cmark#911

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for RFC 3013: Checking conditional compilation at compile time #82450

Tracking Issue for RFC 3013: Checking conditional compilation at compile time #82450

ehuss commented Feb 23, 2021 •

edited by Urgau

Loading

Urgau commented Feb 21, 2022 •

edited

Loading

jhpratt commented Feb 21, 2022

Urgau commented Feb 21, 2022

jhpratt commented Feb 21, 2022 •

edited

Loading

Urgau commented Feb 26, 2022

c410-f3r commented Feb 26, 2022 •

edited

Loading

petrochenkov commented Mar 21, 2022

petrochenkov commented Mar 21, 2022

lcnr commented Mar 21, 2022 •

edited

Loading

rfcbot commented Apr 5, 2024

rfcbot commented Apr 15, 2024

Tracking Issue for RFC 3013: Checking conditional compilation at compile time #82450

Tracking Issue for RFC 3013: Checking conditional compilation at compile time #82450

Comments

ehuss commented Feb 23, 2021 • edited by Urgau Loading

About tracking issues

Steps

Unresolved Questions

Implementation history

Urgau commented Feb 21, 2022 • edited Loading

jhpratt commented Feb 21, 2022

Urgau commented Feb 21, 2022

jhpratt commented Feb 21, 2022 • edited Loading

Urgau commented Feb 26, 2022

c410-f3r commented Feb 26, 2022 • edited Loading

petrochenkov commented Mar 21, 2022

petrochenkov commented Mar 21, 2022

lcnr commented Mar 21, 2022 • edited Loading

rfcbot commented Apr 5, 2024

rfcbot commented Apr 15, 2024

ehuss commented Feb 23, 2021 •

edited by Urgau

Loading

Urgau commented Feb 21, 2022 •

edited

Loading

jhpratt commented Feb 21, 2022 •

edited

Loading

c410-f3r commented Feb 26, 2022 •

edited

Loading

lcnr commented Mar 21, 2022 •

edited

Loading