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 RFC 3013: Checking conditional compilation at compile time #82450

Closed
3 tasks done
ehuss opened this issue Feb 23, 2021 · 42 comments · Fixed by #123501
Closed
3 tasks done

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

ehuss opened this issue Feb 23, 2021 · 42 comments · Fixed by #123501
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-check-cfg --check-cfg finished-final-comment-period The final comment period is finished for this PR / Issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ehuss
Copy link
Contributor

ehuss commented Feb 23, 2021

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

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

@ehuss ehuss added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Feb 23, 2021
@wesleywiser wesleywiser added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Jun 2, 2021
mwkmwkmwk added a commit to mwkmwkmwk/rust that referenced this issue Sep 29, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 18, 2022
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
Copy link
Member

Urgau commented Feb 21, 2022

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
Copy link
Member

jhpratt commented Feb 21, 2022

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
Copy link
Member

Urgau commented Feb 21, 2022

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
Copy link
Member

jhpratt commented Feb 21, 2022

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

@Urgau
Copy link
Member

Urgau commented Feb 26, 2022

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
Copy link
Contributor

c410-f3r commented Feb 26, 2022

Thank you for all the hard work, @Urgau

@petrochenkov
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

lcnr commented Mar 21, 2022

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.

fbq pushed a commit to Rust-for-Linux/linux that referenced this issue Mar 25, 2024
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/20231101-rust-binder-v1-2-08ba9197f637@google.com/#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 <ojeda@kernel.org>
Link: https://lore.kernel.org/r/20240217002717.57507-1-ojeda@kernel.org
fbq pushed a commit to Rust-for-Linux/linux that referenced this issue Mar 29, 2024
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/20231101-rust-binder-v1-2-08ba9197f637@google.com/#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 <ojeda@kernel.org>
Link: https://lore.kernel.org/r/20240217002717.57507-1-ojeda@kernel.org
[boqun: Resolve the conflicts with using upstream alloc]
ojeda added a commit to ojeda/linux that referenced this issue Mar 29, 2024
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/20231101-rust-binder-v1-2-08ba9197f637@google.com/#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 <aliceryhl@google.com>
Tested-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20240217002717.57507-1-ojeda@kernel.org
[ Upgraded to 1.77.1. No changed to `alloc` during the beta. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda added a commit to Rust-for-Linux/linux that referenced this issue Mar 29, 2024
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/20231101-rust-binder-v1-2-08ba9197f637@google.com/#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 <aliceryhl@google.com>
Tested-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20240217002717.57507-1-ojeda@kernel.org
[ 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 <ojeda@kernel.org>
sweettea pushed a commit to sweettea/btrfs-fscrypt that referenced this issue Apr 3, 2024
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/20231101-rust-binder-v1-2-08ba9197f637@google.com/#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 <aliceryhl@google.com>
Tested-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20240217002717.57507-1-ojeda@kernel.org
[ 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 <ojeda@kernel.org>
@rfcbot 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
Copy link

rfcbot commented Apr 5, 2024

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

@rfcbot 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
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Apr 15, 2024
@rfcbot
Copy link

rfcbot commented Apr 15, 2024

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.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 16, 2024
…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`
@bors bors closed this as completed in f54219c Apr 16, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 16, 2024
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``
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label May 3, 2024
bors added a commit to rust-lang/cargo that referenced this issue May 3, 2024
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
imrn99 added a commit to LIHPC-Computational-Geometry/honeycomb that referenced this issue May 6, 2024
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)
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

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
mqudsi added a commit to fish-shell/fish-shell that referenced this issue May 9, 2024
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.
rhysd added a commit to rhysd/wry that referenced this issue May 30, 2024
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 <lin90162@yahoo.co.jp>
pewsheen pushed a commit to tauri-apps/wry that referenced this issue May 30, 2024
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 <lin90162@yahoo.co.jp>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-check-cfg --check-cfg finished-final-comment-period The final comment period is finished for this PR / Issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.