`rustdoc::broken_intra_doc_links` behavior change with `macro_rules` not in scope since 1.63 #106142

ojeda · 2022-12-25T20:08:32Z

rustdoc >= 1.63 complains about this intra-doc link:

pub mod a {
    /// [`m`]
    pub fn f() {}

    #[macro_export]
    macro_rules! m {
        () => {};
    }
}

with:

warning: unresolved link to `m`
 --> c.rs:2:11
  |
2 |     /// [`m`]
  |           ^ no item named `m` in scope
  |
  = note: `macro_rules` named `m` exists in this crate, but it is not in scope at this link's location
  = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default

warning: 1 warning emitted

However, the link is still generated in the rendered output, and points to the right place. Thus the text "unresolved link" is a bit confusing, especially since in earlier versions (<= 1.62), there was no warning for this case (and the link still got generated too).

With e.g. crate::m, the warning goes away.

Therefore, if the intended behavior is that the user writes something like crate::m, then when the user just wrote m the link should not be generated (which would make the text of the lint consistent) or the link could be generated but then the warning should say the link may still be generated.

On the other hand, if the intended behavior is that m still works as-is like in previous versions, then it is a false positive and a regression on the lint.

The text was updated successfully, but these errors were encountered:

petrochenkov · 2022-12-25T20:22:38Z

Duplicate of #98804.

Despite the warning, the generated link does work as expected.

This is a compatibility measure to keep stuff on docs.rs working if possible.

We can probably remove the compatibility case at this point.

ojeda · 2022-12-25T20:34:42Z

Thanks Vadim, indeed it is that one.

We can probably remove the compatibility case at this point.

Sounds great.

ojeda · 2022-12-25T20:55:07Z

By the way, do you want to reuse this issue for the removal? (assuming there is not one already)

…nings Since Rust 1.63.0, `rustdoc` complains with `broken_intra_doc_links` about intra-doc links pointing to exported `macro_rules`, e.g.: error: unresolved link to `dev_info` --> rust/kernel/device.rs:135:43 | 135 | /// More details are available from [`dev_info`]. | ^^^^^^^^ no item named `dev_info` in scope | = note: `macro_rules` named `dev_info` exists in this crate, but it is not in scope at this link's location = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` error: aborting due to previous error The text is confusing, because the link still gets generated, and previous versions (<= 1.62) did not warn and also generated the link. This was reported upstream at [1], and it turns out that the link still being generated was a compatibility measure for docs.rs, which may get removed soon. Thus the intended behavior is that the user specifies the proper path. Therefore, clean up the `allow()`s introduced earlier to satisfy `rustdoc` and the new behavior. Link: rust-lang/rust#106142 [1] Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Tested-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Tested-by: Neal Gompa <neal@gompa.dev> Link: Rust-for-Linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

…nings Since Rust 1.63.0, `rustdoc` complains with `broken_intra_doc_links` about intra-doc links pointing to exported `macro_rules`, e.g.: error: unresolved link to `dev_info` --> rust/kernel/device.rs:135:43 | 135 | /// More details are available from [`dev_info`]. | ^^^^^^^^ no item named `dev_info` in scope | = note: `macro_rules` named `dev_info` exists in this crate, but it is not in scope at this link's location = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` error: aborting due to previous error The text is confusing, because the link still gets generated, and previous versions (<= 1.62) did not warn and also generated the link. This was reported upstream at [1], and it turns out that the link still being generated was a compatibility measure for docs.rs, which may get removed soon. Thus the intended behavior is that the user specifies the proper path. Therefore, clean up the `allow()`s introduced earlier to satisfy `rustdoc` and the new behavior. Link: rust-lang/rust#106142 [1] Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Tested-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Tested-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

…nings Since Rust 1.63.0, `rustdoc` complains with `broken_intra_doc_links` about intra-doc links pointing to exported `macro_rules`, e.g.: error: unresolved link to `dev_info` --> rust/kernel/device.rs:135:43 | 135 | /// More details are available from [`dev_info`]. | ^^^^^^^^ no item named `dev_info` in scope | = note: `macro_rules` named `dev_info` exists in this crate, but it is not in scope at this link's location = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` error: aborting due to previous error The text is confusing, because the link still gets generated, and previous versions (<= 1.62) did not warn and also generated the link. This was reported upstream at [1], and it turns out that the link still being generated was a compatibility measure for docs.rs, which may get removed soon. Thus the intended behavior is that the user specifies the proper path. Therefore, clean up the `allow()`s introduced earlier to satisfy `rustdoc` and the new behavior. Link: rust-lang/rust#106142 [1] Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Tested-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Tested-by: Neal Gompa <neal@gompa.dev> Link: Rust-for-Linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

…nings Since Rust 1.63.0, `rustdoc` complains with `broken_intra_doc_links` about intra-doc links pointing to exported `macro_rules`, e.g.: error: unresolved link to `dev_info` --> rust/kernel/device.rs:135:43 | 135 | /// More details are available from [`dev_info`]. | ^^^^^^^^ no item named `dev_info` in scope | = note: `macro_rules` named `dev_info` exists in this crate, but it is not in scope at this link's location = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` error: aborting due to previous error The text is confusing, because the link still gets generated, and previous versions (<= 1.62) did not warn and also generated the link. This was reported upstream at [1], and it turns out that the link still being generated was a compatibility measure for docs.rs, which may get removed soon. Thus the intended behavior is that the user specifies the proper path. Therefore, clean up the `allow()`s introduced earlier to satisfy `rustdoc` and the new behavior. Link: rust-lang/rust#106142 [1] Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Tested-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Tested-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Tested-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Tested-by: Neal Gompa <neal@gompa.dev> Link: Rust-for-Linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

`Arc<T>::init` refers to `Arc<T>::pin_init` via an intra-doc link using the text `pin_init`, rather than more explicitly, which makes `rustdoc` point it to the `pin_init!` macro instead. This is required for the compiler upgrade since the newer `rustdoc` would trigger the `broken_intra_doc_links` lint [1], but in this case the macro was not the intended target to begin with, and so the actual fix is to make it point to the right place, regardless of the upgrade. Thus make it more explicit. Fixes: 92c4a1e ("rust: init/sync: add `InPlaceInit` trait to pin-initialize smart pointers") Link: rust-lang/rust#106142 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

This is the first upgrade to the Rust toolchain since the initial Rust merge, from 1.62.0 to 1.68.2 (i.e. the latest). # Context The kernel currently supports only a single Rust version [1] (rather than a minimum) given our usage of some "unstable" Rust features [2] which do not promise backwards compatibility. The goal is to reach a point where we can declare a minimum version for the toolchain. For instance, by waiting for some of the features to be stabilized. Therefore, the first minimum Rust version that the kernel will support is "in the future". # Upgrade policy Given we will eventually need to reach that minimum version, it would be ideal to upgrade the compiler from time to time to be as close as possible to that goal and find any issues sooner. In the extreme, we could upgrade as soon as a new Rust release is out. Of course, upgrading so often is in stark contrast to what one normally would need for GCC and LLVM, especially given the release schedule: 6 weeks for Rust vs. half a year for LLVM and a year for GCC. Having said that, there is no particular advantage to updating slowly either: kernel developers in "stable" distributions are unlikely to be able to use their distribution-provided Rust toolchain for the kernel anyway [3]. Instead, by routinely upgrading to the latest instead, kernel developers using Linux distributions that track the latest Rust release may be able to use those rather than Rust-provided ones, especially if their package manager allows to pin / hold back / downgrade the version for some days during windows where the version may not match. For instance, Arch, Fedora, Gentoo and openSUSE all provide and track the latest version of Rust as they get released every 6 weeks. Then, when the minimum version is reached, we will stop upgrading and decide how wide the window of support will be. For instance, a year of Rust versions. We will probably want to start small, and then widen it over time, just like the kernel did originally for LLVM, see commit 3519c4d ("Documentation: add minimum clang/llvm version"). # Unstable features stabilized This upgrade allows us to remove the following unstable features since they were stabilized: - `feature(explicit_generic_args_with_impl_trait)` (1.63). - `feature(core_ffi_c)` (1.64). - `feature(generic_associated_types)` (1.65). - `feature(const_ptr_offset_from)` (1.65, *). - `feature(bench_black_box)` (1.66, *). - `feature(pin_macro)` (1.68). The ones marked with `*` apply only to our old `rust` branch, not mainline yet, i.e. only for code that we may potentially upstream. With this patch applied, the only unstable feature allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [2] for details. # Other required changes Since 1.63, `rustdoc` triggers the `broken_intra_doc_links` lint for links pointing to exported (`#[macro_export]`) `macro_rules`. An issue was opened upstream [4], but it turns out it is intended behavior. For the moment, just add an explicit reference for each link. Later we can revisit this if `rustdoc` removes the compatibility measure. Nevertheless, this was helpful to discover a link that was pointing to the wrong place unintentionally. Since that one was actually wrong, it is fixed in a previous commit independently. Another change was the addition of `cfg(no_rc)` and `cfg(no_sync)` in upstream [5], thus remove our original changes for that. Similarly, upstream now tests that it compiles successfully with `#[cfg(not(no_global_oom_handling))]` [6], which allow us to get rid of some changes, such as an `#[allow(dead_code)]`. In addition, remove another `#[allow(dead_code)]` due to new uses within the standard library. Finally, add `try_extend_trusted` and move the code in `spec_extend.rs` since upstream moved it for the infallible version. # `alloc` upgrade and reviewing There are a large amount of changes, but the vast majority of them 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://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux#2 [2] Link: https://lore.kernel.org/rust-for-linux/CANiq72mT3bVDKdHgaea-6WiZazd8Mvurqmqegbe5JZxVyLR8Yg@mail.gmail.com/ [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#89891 [5] Link: rust-lang/rust#98652 [6] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Upgrade the Rust version from 1.62.0 to 1.66.0. The overwhelming majority of the commit is about upgrading our `alloc` fork to the new version from upstream [1]. License has not changed [2][3] (there were changes in the `COPYRIGHT` file, but unrelated to `alloc`). As in the previous version upgrades (done out of tree so far), upgrading `alloc` requires checking that our small additions (`try_*`) still match their original (non`-try_*`) versions. With this version upgrade, the following unstable Rust features were stabilized: `bench_black_box` (1.66.0), `const_ptr_offset_from` (1.65.0), `core_ffi_c` (1.64.0) and `generic_associated_types` (1.65.0). Thus remove them. This also implies that only two unstable features remain allowed for non-`rust/` code: `allocator_api` and `const_refs_to_cell`. There are some new Clippy warnings that we are triggering (i.e. introduced since 1.62.0), as well as a few others that were not triggered before, thus allow them in this commit and clean up or remove them as needed later on: - `borrow_deref_ref` (new in 1.63.0). - `explicit_auto_deref` (new in 1.64.0). - `bool_to_int_with_if` (new in 1.65.0). - `needless_borrow`. - `type_complexity`. - `unnecessary_cast` (allowed only on `CONFIG_ARM`). Furthermore, `rustdoc` lint `broken_intra_doc_links` is triggering on links pointing to `macro_export` `macro_rules` defined in the same module (i.e. appearing in the crate root). However, even if the warning appears, the link still gets generated like in previous versions, thus it is a bit confusing. An issue has been opened upstream [4], and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior (done in the next patch). In addition, there is an added `#[const_trait]` attribute in `RawDeviceId`, due to 1.66.0's PR "Require `#[const_trait]` on `Trait` for `impl const Trait`") [5]. Finally, the `-Aunused-imports` was added for compiling `core`. This was fixed upstream for 1.67.0 in PR "Fix warning when libcore is compiled with no_fp_fmt_parse" [6], and prevented for the future for that `cfg` in PR "core: ensure `no_fp_fmt_parse builds` are warning-free" [7]. Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Tested-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Tested-by: Neal Gompa <neal@gompa.dev> Link: Rust-for-Linux#947 Link: https://github.com/rust-lang/rust/tree/1.66.0/library/alloc/src [1] Link: https://github.com/rust-lang/rust/blob/1.66.0/library/alloc/Cargo.toml#L4 [2] Link: https://github.com/rust-lang/rust/blob/1.66.0/COPYRIGHT [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#100982 [5] Link: rust-lang/rust#105434 [6] Link: rust-lang/rust#105811 [7] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

This is the first upgrade to the Rust toolchain since the initial Rust merge, from 1.62.0 to 1.68.2 (i.e. the latest). # Context The kernel currently supports only a single Rust version [1] (rather than a minimum) given our usage of some "unstable" Rust features [2] which do not promise backwards compatibility. The goal is to reach a point where we can declare a minimum version for the toolchain. For instance, by waiting for some of the features to be stabilized. Therefore, the first minimum Rust version that the kernel will support is "in the future". # Upgrade policy Given we will eventually need to reach that minimum version, it would be ideal to upgrade the compiler from time to time to be as close as possible to that goal and find any issues sooner. In the extreme, we could upgrade as soon as a new Rust release is out. Of course, upgrading so often is in stark contrast to what one normally would need for GCC and LLVM, especially given the release schedule: 6 weeks for Rust vs. half a year for LLVM and a year for GCC. Having said that, there is no particular advantage to updating slowly either: kernel developers in "stable" distributions are unlikely to be able to use their distribution-provided Rust toolchain for the kernel anyway [3]. Instead, by routinely upgrading to the latest instead, kernel developers using Linux distributions that track the latest Rust release may be able to use those rather than Rust-provided ones, especially if their package manager allows to pin / hold back / downgrade the version for some days during windows where the version may not match. For instance, Arch, Fedora, Gentoo and openSUSE all provide and track the latest version of Rust as they get released every 6 weeks. Then, when the minimum version is reached, we will stop upgrading and decide how wide the window of support will be. For instance, a year of Rust versions. We will probably want to start small, and then widen it over time, just like the kernel did originally for LLVM, see commit 3519c4d ("Documentation: add minimum clang/llvm version"). # Unstable features stabilized This upgrade allows us to remove the following unstable features since they were stabilized: - `feature(explicit_generic_args_with_impl_trait)` (1.63). - `feature(core_ffi_c)` (1.64). - `feature(generic_associated_types)` (1.65). - `feature(const_ptr_offset_from)` (1.65, *). - `feature(bench_black_box)` (1.66, *). - `feature(pin_macro)` (1.68). The ones marked with `*` apply only to our old `rust` branch, not mainline yet, i.e. only for code that we may potentially upstream. With this patch applied, the only unstable feature allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [2] for details. # Other required changes Since 1.63, `rustdoc` triggers the `broken_intra_doc_links` lint for links pointing to exported (`#[macro_export]`) `macro_rules`. An issue was opened upstream [4], but it turns out it is intended behavior. For the moment, just add an explicit reference for each link. Later we can revisit this if `rustdoc` removes the compatibility measure. Nevertheless, this was helpful to discover a link that was pointing to the wrong place unintentionally. Since that one was actually wrong, it is fixed in a previous commit independently. Another change was the addition of `cfg(no_rc)` and `cfg(no_sync)` in upstream [5], thus remove our original changes for that. Similarly, upstream now tests that it compiles successfully with `#[cfg(not(no_global_oom_handling))]` [6], which allow us to get rid of some changes, such as an `#[allow(dead_code)]`. In addition, remove another `#[allow(dead_code)]` due to new uses within the standard library. Finally, add `try_extend_trusted` and move the code in `spec_extend.rs` since upstream moved it for the infallible version. # `alloc` upgrade and reviewing There are a large amount of changes, but the vast majority of them 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://rust-for-linux.com/rust-version-policy [1] Link: Rust-for-Linux/linux#2 [2] Link: https://lore.kernel.org/rust-for-linux/CANiq72mT3bVDKdHgaea-6WiZazd8Mvurqmqegbe5JZxVyLR8Yg@mail.gmail.com/ [3] Link: rust-lang/rust#106142 [4] Link: rust-lang/rust#89891 [5] Link: rust-lang/rust#98652 [6] Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-By: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Tested-by: Ariel Miculas <amiculas@cisco.com> Tested-by: David Gow <davidgow@google.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20230418214347.324156-4-ojeda@kernel.org [ Removed `feature(core_ffi_c)` from `uapi` ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

`Arc<T>::init` refers to `Arc<T>::pin_init` via an intra-doc link using the text `pin_init`, rather than more explicitly, which makes `rustdoc` point it to the `pin_init!` macro instead. This is required for the compiler upgrade since the newer `rustdoc` would trigger the `broken_intra_doc_links` lint [1], but in this case the macro was not the intended target to begin with, and so the actual fix is to make it point to the right place, regardless of the upgrade. Thus make it more explicit. Fixes: 92c4a1e ("rust: init/sync: add `InPlaceInit` trait to pin-initialize smart pointers") Link: rust-lang/rust#106142 [1] Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Tested-by: Ariel Miculas <amiculas@cisco.com> Tested-by: David Gow <davidgow@google.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20230418214347.324156-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>