rust: upgrade to Rust 1.66.0 #947

ojeda · 2022-12-25T23:47:12Z

Required changes:

Some new Clippy warnings (introduced since 1.62.0), as well as a few others that weren't triggered before, to be cleaned up or disabled 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 (this one I allowed it only on CONFIG_ARM).
rustdoc lint broken_intra_doc_links 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 -- I opened rustdoc::broken_intra_doc_links behavior change with macro_rules not in scope since 1.63 rust-lang/rust#106142, and it appears that the link still being generated was a compatibility measure, thus we will need to adapt to the new behavior.
- Thus I went ahead and cleaned those up in the second commit.
#[const_trait] in RawDeviceId (1.66.0 due to Require #[const_trait] on Trait for impl const Trait rust-lang/rust#100982)
-Aunused-imports for core, fixed upstream in Fix warning when libcore is compiled with no_fp_fmt_parse rust-lang/rust#105434, and prevented for the future for that cfg in core: ensure no_fp_fmt_parse builds are warning-free rust-lang/rust#105811.

I will have to reword the first commit for upstreaming and possibly split it somehow to make it easier to read. For the moment, this should unblock those waiting for 1.66.0 and start testing it on our side.

As a triple-check, I redid the functions by hand and spotted a doc sentence missed from an old upgrade. Nothing important, but I included it here as the third commit too.

Signed-off-by: Miguel Ojeda ojeda@kernel.org

Conan-Kudo · 2022-12-26T00:32:12Z

cc: @marcan @davide125

aliceinwire · 2022-12-26T07:40:37Z

Few of this problem are referenced in the following PR:

borrow_deref_ref (new in 1.63.0) rust: kernel: workqueue: deref on an immutable reference #900
macros: error: use type definitions for reduce complexity #898 very complex type used

aliceinwire · 2022-12-26T07:44:31Z

rust/macros/module.rs

@@ -143,6 +143,7 @@ fn param_ops_path(param_type: &str) -> &'static str {
    }
 }

+#[allow(clippy::type_complexity)]


Referenced in PR #898

Thanks Alice!

bjorn3 · 2022-12-26T08:52:43Z

rust/kernel/driver.rs

@@ -119,6 +119,7 @@ impl<T: DriverOps> Drop for Registration<T> {
 ///   - [`RawDeviceId::ZERO`] is actually a zeroed-out version of the raw device id.
 ///   - [`RawDeviceId::to_rawid`] stores `offset` in the context/data field of the raw device id so
 ///     that buses can recover the pointer to the data.
+#[const_trait]


Did something break without this?

It was due to (added it to OP):

error: ~const can only be applied to `#[const_trait]` traits --> rust/kernel/driver.rs:156:19 | 156 | T: ~const RawDeviceId + Copy, | ^^^^^^^^^^^ error: const `impl` for trait `RawDeviceId` which is not marked with `#[const_trait]` --> rust/kernel/of.rs:40:19 | 40 | unsafe impl const driver::RawDeviceId for DeviceId { | ^^^^^^^^^^^^^^^^^^^ | ::: rust/kernel/driver.rs:122:1 | 122 | pub unsafe trait RawDeviceId { | - help: mark `RawDeviceId` as const: `#[const_trait]` | = note: marking a trait with `#[const_trait]` ensures all default method bodies are `const` = note: adding a non-const method body in the future would be a breaking change error: aborting due to 2 previous errors

alex · 2022-12-26T14:01:18Z

Only did a limited review, but LGTM.

YakoYakoYokuYoku · 2022-12-26T14:22:30Z

Builds without warnings, LGTM

Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Tested-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>

Conan-Kudo · 2022-12-26T14:22:39Z

cc: @asahilina

ojeda · 2022-12-26T16:33:13Z

Thanks everyone! That was awesome.

@nbdd0121 @vincenzopalazzo @bjorn3 I am transforming your GH approvals into Reviewed-bys -- let me know if you didn't intend that (in which case I will remove it when I submit it for upstream).

ojeda · 2022-12-26T16:36:42Z

v2: no changes, just collected the tags.

aliceinwire · 2022-12-26T18:00:01Z

Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com>
Tested-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com>

Conan-Kudo · 2022-12-26T18:25:01Z

Running a test build now with this PR:

Conan-Kudo

So my build is fixed, but the result seems to cause Xorg to crash. This probably means that @asahilina needs to adapt her code to Rust 1.66.

Otherwise, this looks reasonable.

Reviewed-by: Neal Gompa <neal@gompa.dev>
Tested-by: Neal Gompa <neal@gompa.dev>

Conan-Kudo · 2022-12-26T21:24:56Z

Also, it probably makes sense to add Reported-by: Neal Gompa <neal@gompa.dev> here, since this was triggered by my post in the Zulip.

Rust 1.66.0 will be the next version supported by the kernel [1]. Therefore, add `rustc-1.66` as a new build environment alongside `rustc-1.62` (which can be removed later on when the new version hits mainline). Link: Rust-for-Linux/linux#947 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

The `rust` branch of `rust-for-linux` is moving to Rust 1.66.0 [1], therefore, use the new build environment for it. Link: Rust-for-Linux/linux#947 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Conan-Kudo

Actually, we apparently tested the wrong kernel build. The correct kernel build works, so I give this a total 👍🏾

Reported-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Tested-by: Neal Gompa <neal@gompa.dev>

Conan-Kudo · 2022-12-27T15:20:35Z

I also needed a minor tweak from @ericcurtin to get bindgen working too: https://gitlab.com/fedora-asahi/kernel-asahi/-/commit/7407fdf7716f3233da56a5fb4e2e28fffb775fa5

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>

An update missing from Rust 1.57.0. The comment was added in upstream commit e8e7f6e05cf6 ("Add truncate note to Vec::resize") to `resize`, but not to our fallible version `try_resize`. Fixes: 7aaec26 ("rust: alloc: upgrade to 1.57.0") 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>

Rust 1.66.0 will be the next version supported by the kernel [1]. Therefore, add `rustc-1.66` as a new build environment alongside `rustc-1.62` (which can be removed later on when the new version hits mainline). Link: Rust-for-Linux/linux#947 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

The `rust` branch of `rust-for-linux` is moving to Rust 1.66.0 [1], therefore, use the new build environment for it. Link: Rust-for-Linux/linux#947 [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

ojeda · 2023-01-11T14:00:08Z

Thanks a lot for the extra reviews & tests, @aliceinwire and @Conan-Kudo, very much appreciated.

v3: tags collected for the forthcoming merge and added a proper commit message for the first patch.

Also, it probably makes sense to add Reported-by: Neal Gompa neal@gompa.dev here, since this was triggered by my post in the Zulip.

Reported-by is meant for bugs only according to the docs. In any case, version upgrades will keep happening until we reach a stable release, and others (e.g. @bjorn3 if I recall correctly) suggested/discussed the 1.66 upgrade in the past. For non-routine version upgrades, we could perhaps do Suggested-bys, but really they make sense only after we are in a stable situation.

ojeda · 2023-01-11T14:13:48Z

Via the button (we don't push on this branch). I have been experiencing GitHub timeouts very often in the last few days, too (e.g. some minutes ago when clicking the "Compare" button above for v2..v3).

rust: upgrade to Rust 1.66.0

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>

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/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>

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>

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/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>

aliceinwire reviewed Dec 26, 2022

View reviewed changes

bjorn3 reviewed Dec 26, 2022

View reviewed changes

bjorn3 approved these changes Dec 26, 2022

View reviewed changes

nbdd0121 approved these changes Dec 26, 2022

View reviewed changes

vincenzopalazzo approved these changes Dec 26, 2022

View reviewed changes

ojeda force-pushed the 1.66.0 branch from 924ca86 to 602c5ec Compare December 26, 2022 16:36

ojeda mentioned this pull request Dec 26, 2022

Rust 1.66.0 kernelci/kernelci-core#1597

Merged

aliceinwire approved these changes Dec 26, 2022

View reviewed changes

Conan-Kudo approved these changes Dec 26, 2022

View reviewed changes

Conan-Kudo approved these changes Dec 27, 2022

View reviewed changes

ojeda added 3 commits January 11, 2023 00:18

ojeda force-pushed the 1.66.0 branch from 602c5ec to c93ddbb Compare January 11, 2023 13:57

ojeda closed this Jan 11, 2023

ojeda deleted the 1.66.0 branch January 11, 2023 15:33

y86-dev pushed a commit to y86-dev/linux that referenced this pull request Jan 11, 2023

Merge pull request Rust-for-Linux#947 from ojeda/1.66.0

84b0fc2

rust: upgrade to Rust 1.66.0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rust: upgrade to Rust 1.66.0 #947

rust: upgrade to Rust 1.66.0 #947

ojeda commented Dec 25, 2022 •

edited

Loading

Conan-Kudo commented Dec 26, 2022

aliceinwire commented Dec 26, 2022

aliceinwire Dec 26, 2022 •

edited

Loading

ojeda Dec 26, 2022

bjorn3 Dec 26, 2022

ojeda Dec 26, 2022

alex commented Dec 26, 2022

YakoYakoYokuYoku commented Dec 26, 2022

Conan-Kudo commented Dec 26, 2022

ojeda commented Dec 26, 2022

ojeda commented Dec 26, 2022

aliceinwire commented Dec 26, 2022

Conan-Kudo commented Dec 26, 2022

Conan-Kudo left a comment •

edited

Loading

Conan-Kudo commented Dec 26, 2022

Conan-Kudo left a comment

Conan-Kudo commented Dec 27, 2022

ojeda commented Jan 11, 2023

ojeda commented Jan 11, 2023 •

edited

Loading

rust: upgrade to Rust 1.66.0 #947

rust: upgrade to Rust 1.66.0 #947

Conversation

ojeda commented Dec 25, 2022 • edited Loading

Conan-Kudo commented Dec 26, 2022

aliceinwire commented Dec 26, 2022

aliceinwire Dec 26, 2022 • edited Loading

Choose a reason for hiding this comment

ojeda Dec 26, 2022

Choose a reason for hiding this comment

bjorn3 Dec 26, 2022

Choose a reason for hiding this comment

ojeda Dec 26, 2022

Choose a reason for hiding this comment

alex commented Dec 26, 2022

YakoYakoYokuYoku commented Dec 26, 2022

Conan-Kudo commented Dec 26, 2022

ojeda commented Dec 26, 2022

ojeda commented Dec 26, 2022

aliceinwire commented Dec 26, 2022

Conan-Kudo commented Dec 26, 2022

Conan-Kudo left a comment • edited Loading

Choose a reason for hiding this comment

Conan-Kudo commented Dec 26, 2022

Conan-Kudo left a comment

Choose a reason for hiding this comment

Conan-Kudo commented Dec 27, 2022

ojeda commented Jan 11, 2023

ojeda commented Jan 11, 2023 • edited Loading

ojeda commented Dec 25, 2022 •

edited

Loading

aliceinwire Dec 26, 2022 •

edited

Loading

Conan-Kudo left a comment •

edited

Loading

ojeda commented Jan 11, 2023 •

edited

Loading