[PATCH 0/3] Rust 1.68.2 upgrade

[PATCH 0/3] Rust 1.68.2 upgrade

[Miguel Ojeda]

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).

Please see the last patch message for a long explanation of the upgrade,
the policy for future upgrades and some indications on how to easily
review this.

The series is based on `rust-next`.

Miguel Ojeda (3):
  rust: alloc: clarify what is the upstream version
  rust: arc: fix intra-doc link in `Arc<T>::init`
  rust: upgrade to Rust 1.68.2

 Documentation/process/changes.rst |   2 +-
 rust/alloc/README.md              |   3 +
 rust/alloc/alloc.rs               |  55 ++--
 rust/alloc/boxed.rs               | 446 ++++++++++++++++++++++++++--
 rust/alloc/collections/mod.rs     |   5 +-
 rust/alloc/lib.rs                 |  71 +++--
 rust/alloc/raw_vec.rs             |  16 +-
 rust/alloc/slice.rs               | 447 ++++------------------------
 rust/alloc/vec/drain.rs           |  81 +++++-
 rust/alloc/vec/drain_filter.rs    |  60 +++-
 rust/alloc/vec/into_iter.rs       | 125 ++++++--
 rust/alloc/vec/is_zero.rs         |  96 ++++++-
 rust/alloc/vec/mod.rs             | 464 +++++++++++++++++++++++-------
 rust/alloc/vec/set_len_on_drop.rs |   5 +
 rust/alloc/vec/spec_extend.rs     |  63 +---
 rust/bindings/lib.rs              |   1 -
 rust/kernel/build_assert.rs       |   2 +
 rust/kernel/init.rs               |   5 +
 rust/kernel/lib.rs                |   4 -
 rust/kernel/std_vendor.rs         |   2 +
 rust/kernel/sync/arc.rs           |   2 +-
 scripts/Makefile.build            |   2 +-
 scripts/min-tool-version.sh       |   2 +-
 23 files changed, 1278 insertions(+), 681 deletions(-)

-- 
2.40.0

[PATCH 1/3] rust: alloc: clarify what is the upstream version

[Miguel Ojeda]

It may be unclear for readers which upstream Rust version these files
are based on. They may be unaware that they are intended to match the
minimum (and only, so far) supported version of Rust in the kernel.

Thus clarify it.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/alloc/README.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/rust/alloc/README.md b/rust/alloc/README.md
index c89c753720b5..eb6f22e94ebf 100644
--- a/rust/alloc/README.md
+++ b/rust/alloc/README.md
@@ -10,6 +10,9 @@ upstream. In general, only additions should be performed (e.g. new
 methods). Eventually, changes should make it into upstream so that,
 at some point, this fork can be dropped from the kernel tree.
 
+The Rust upstream version on top of which these files are based matches
+the output of `scripts/min-tool-version.sh rustc`.
+
 
 ## Rationale
 
-- 
2.40.0

Re: [PATCH 1/3] rust: alloc: clarify what is the upstream version

[Martin Rodriguez Reboredo]

On 4/18/23 18:43, Miguel Ojeda wrote:
> It may be unclear for readers which upstream Rust version these files
> are based on. They may be unaware that they are intended to match the
> minimum (and only, so far) supported version of Rust in the kernel.
> 
> Thus clarify it.
> 
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  rust/alloc/README.md | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/rust/alloc/README.md b/rust/alloc/README.md
> index c89c753720b5..eb6f22e94ebf 100644
> --- a/rust/alloc/README.md
> +++ b/rust/alloc/README.md
> @@ -10,6 +10,9 @@ upstream. In general, only additions should be performed (e.g. new
>  methods). Eventually, changes should make it into upstream so that,
>  at some point, this fork can be dropped from the kernel tree.
>  
> +The Rust upstream version on top of which these files are based matches
> +the output of `scripts/min-tool-version.sh rustc`.
> +
>  
>  ## Rationale
>  

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

Re: [PATCH 1/3] rust: alloc: clarify what is the upstream version

[Benno Lossin]

On 18.04.23 23:43, Miguel Ojeda wrote:
> It may be unclear for readers which upstream Rust version these files
> are based on. They may be unaware that they are intended to match the
> minimum (and only, so far) supported version of Rust in the kernel.
> 
> Thus clarify it.
> 
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Benno Lossin <benno.lossin@proton.me>

> ---
>   rust/alloc/README.md | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/rust/alloc/README.md b/rust/alloc/README.md
> index c89c753720b5..eb6f22e94ebf 100644
> --- a/rust/alloc/README.md
> +++ b/rust/alloc/README.md
> @@ -10,6 +10,9 @@ upstream. In general, only additions should be performed (e.g. new
>   methods). Eventually, changes should make it into upstream so that,
>   at some point, this fork can be dropped from the kernel tree.
> 
> +The Rust upstream version on top of which these files are based matches
> +the output of `scripts/min-tool-version.sh rustc`.
> +
> 
>   ## Rationale
> 
> --
> 2.40.0
>

Re: [PATCH 1/3] rust: alloc: clarify what is the upstream version

[Gary Guo]

On Tue, 18 Apr 2023 23:43:45 +0200
Miguel Ojeda <ojeda@kernel.org> wrote:

> It may be unclear for readers which upstream Rust version these files
> are based on. They may be unaware that they are intended to match the
> minimum (and only, so far) supported version of Rust in the kernel.
> 
> Thus clarify it.
> 
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Gary Guo <gary@garyguo.net>

> ---
>  rust/alloc/README.md | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/rust/alloc/README.md b/rust/alloc/README.md
> index c89c753720b5..eb6f22e94ebf 100644
> --- a/rust/alloc/README.md
> +++ b/rust/alloc/README.md
> @@ -10,6 +10,9 @@ upstream. In general, only additions should be performed (e.g. new
>  methods). Eventually, changes should make it into upstream so that,
>  at some point, this fork can be dropped from the kernel tree.
>  
> +The Rust upstream version on top of which these files are based matches
> +the output of `scripts/min-tool-version.sh rustc`.
> +
>  
>  ## Rationale
>  

Re: [PATCH 1/3] rust: alloc: clarify what is the upstream version

[Björn Roy Baron]

On Tuesday, April 18th, 2023 at 23:43, Miguel Ojeda <ojeda@kernel.org> wrote:

> It may be unclear for readers which upstream Rust version these files
> are based on. They may be unaware that they are intended to match the
> minimum (and only, so far) supported version of Rust in the kernel.
> 
> Thus clarify it.
> 
> Signed-off-by: Miguel Ojeda ojeda@kernel.org

Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>

> 
> ---
>  rust/alloc/README.md | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/rust/alloc/README.md b/rust/alloc/README.md
> index c89c753720b5..eb6f22e94ebf 100644
> --- a/rust/alloc/README.md
> +++ b/rust/alloc/README.md
> @@ -10,6 +10,9 @@ upstream. In general, only additions should be performed (e.g. new
>  methods). Eventually, changes should make it into upstream so that,
>  at some point, this fork can be dropped from the kernel tree.
> 
> +The Rust upstream version on top of which these files are based matches
> +the output of `scripts/min-tool-version.sh rustc`.
> +
> 
>  ## Rationale
> 
> --
> 2.40.0

[PATCH 2/3] rust: arc: fix intra-doc link in `Arc<T>::init`

[Miguel Ojeda]

`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: 92c4a1e7e81c ("rust: init/sync: add `InPlaceInit` trait to pin-initialize smart pointers")
Link: https://github.com/rust-lang/rust/issues/106142 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/kernel/sync/arc.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
index e6d206242465..1b0734fdf6a7 100644
--- a/rust/kernel/sync/arc.rs
+++ b/rust/kernel/sync/arc.rs
@@ -185,7 +185,7 @@ impl<T> Arc<T> {
 
     /// Use the given initializer to in-place initialize a `T`.
     ///
-    /// This is equivalent to [`pin_init`], since an [`Arc`] is always pinned.
+    /// This is equivalent to [`Arc<T>::pin_init`], since an [`Arc`] is always pinned.
     #[inline]
     pub fn init<E>(init: impl Init<T, E>) -> error::Result<Self>
     where
-- 
2.40.0

Re: [PATCH 2/3] rust: arc: fix intra-doc link in `Arc<T>::init`

[Martin Rodriguez Reboredo]

On 4/18/23 18:43, Miguel Ojeda wrote:
> `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: 92c4a1e7e81c ("rust: init/sync: add `InPlaceInit` trait to pin-initialize smart pointers")
> Link: https://github.com/rust-lang/rust/issues/106142 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  rust/kernel/sync/arc.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index e6d206242465..1b0734fdf6a7 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -185,7 +185,7 @@ impl<T> Arc<T> {
>  
>      /// Use the given initializer to in-place initialize a `T`.
>      ///
> -    /// This is equivalent to [`pin_init`], since an [`Arc`] is always pinned.
> +    /// This is equivalent to [`Arc<T>::pin_init`], since an [`Arc`] is always pinned.
>      #[inline]
>      pub fn init<E>(init: impl Init<T, E>) -> error::Result<Self>
>      where

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

Re: [PATCH 2/3] rust: arc: fix intra-doc link in `Arc<T>::init`

[Benno Lossin]

On 18.04.23 23:43, Miguel Ojeda wrote:
> `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: 92c4a1e7e81c ("rust: init/sync: add `InPlaceInit` trait to pin-initialize smart pointers")
> Link: https://github.com/rust-lang/rust/issues/106142 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Benno Lossin <benno.lossin@proton.me>

> ---
>   rust/kernel/sync/arc.rs | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index e6d206242465..1b0734fdf6a7 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -185,7 +185,7 @@ impl<T> Arc<T> {
> 
>       /// Use the given initializer to in-place initialize a `T`.
>       ///
> -    /// This is equivalent to [`pin_init`], since an [`Arc`] is always pinned.
> +    /// This is equivalent to [`Arc<T>::pin_init`], since an [`Arc`] is always pinned.
>       #[inline]
>       pub fn init<E>(init: impl Init<T, E>) -> error::Result<Self>
>       where
> --
> 2.40.0
>

Re: [PATCH 2/3] rust: arc: fix intra-doc link in `Arc<T>::init`

[Gary Guo]

On Tue, 18 Apr 2023 23:43:46 +0200
Miguel Ojeda <ojeda@kernel.org> wrote:

> `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: 92c4a1e7e81c ("rust: init/sync: add `InPlaceInit` trait to pin-initialize smart pointers")
> Link: https://github.com/rust-lang/rust/issues/106142 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Gary Guo <gary@garyguo.net>

> ---
>  rust/kernel/sync/arc.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index e6d206242465..1b0734fdf6a7 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -185,7 +185,7 @@ impl<T> Arc<T> {
>  
>      /// Use the given initializer to in-place initialize a `T`.
>      ///
> -    /// This is equivalent to [`pin_init`], since an [`Arc`] is always pinned.
> +    /// This is equivalent to [`Arc<T>::pin_init`], since an [`Arc`] is always pinned.
>      #[inline]
>      pub fn init<E>(init: impl Init<T, E>) -> error::Result<Self>
>      where

Re: [PATCH 2/3] rust: arc: fix intra-doc link in `Arc<T>::init`

[Björn Roy Baron]

On Tuesday, April 18th, 2023 at 23:43, Miguel Ojeda <ojeda@kernel.org> wrote:

> `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: 92c4a1e7e81c ("rust: init/sync: add `InPlaceInit` trait to pin-initialize smart pointers")
> Link: https://github.com/rust-lang/rust/issues/106142 [1]
> Signed-off-by: Miguel Ojeda ojeda@kernel.org

Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>

> 
> ---
>  rust/kernel/sync/arc.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index e6d206242465..1b0734fdf6a7 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -185,7 +185,7 @@ impl<T> Arc<T> {
> 
>      /// Use the given initializer to in-place initialize a `T`.
>      ///
> -    /// This is equivalent to [`pin_init`], since an [`Arc`] is always pinned.
> +    /// This is equivalent to [`Arc<T>::pin_init`], since an [`Arc`] is always pinned.
>      #[inline]
>      pub fn init<E>(init: impl Init<T, E>) -> error::Result<Self>
>      where
> --
> 2.40.0

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Miguel Ojeda]

On Tue, Apr 18, 2023 at 11:44 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> 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).
>
> Please see the last patch message for a long explanation of the upgrade,
> the policy for future upgrades and some indications on how to easily
> review this.
>
> The series is based on `rust-next`.

The third patch may be too big for vger -- for those looking for it,
Lore has it at https://lore.kernel.org/all/20230418214347.324156-4-ojeda@kernel.org/

Cheers,
Miguel

Re: [PATCH 3/3] rust: upgrade to Rust 1.68.2

[Martin Rodriguez Reboredo]

On 4/18/23 18:43, Miguel Ojeda wrote:
> [...]

Kinda bunch to review, although may I ask if each time the `alloc`
crate is updated is worth to mention the changes upon it [1], can be
skipped otherwise.

Link: https://github.com/rust-lang/rust/commits/master/library/alloc [1]

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

Re: [PATCH 3/3] rust: upgrade to Rust 1.68.2

[Miguel Ojeda]

On Wed, Apr 19, 2023 at 5:02 AM Martin Rodriguez Reboredo
<yakoyoku@gmail.com> wrote:
>
> Kinda bunch to review, although may I ask if each time the `alloc`
> crate is updated is worth to mention the changes upon it [1], can be
> skipped otherwise.
>
> Link: https://github.com/rust-lang/rust/commits/master/library/alloc [1]

That could be nice if we could give a link similar to, say, what:

    git log 1.62.0..1.68.2 -- library/alloc/src/

produces (or perhaps a list of PRs) -- is it possible to do so with a
GitHub URL? If so, please let me know!

Cheers,
Miguel

Re: [PATCH 3/3] rust: upgrade to Rust 1.68.2

[Miguel Ojeda]

On Wed, May 31, 2023 at 9:48 PM Martin Rodriguez Reboredo
<yakoyoku@gmail.com> wrote:
>
> It seems that kind of URL comparisons in GitHub aren't supported yet
> per the docs say [1]. Sad but maybe in the future they are going to be
> supported, or at least I hope GitLab or Gitea do it.
>
> Link: https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits [1]

Thanks! There is also "comparing releases" [1], but it does not seem
to allow to restrict to a folder... :(

A dedicated view where one could navigate everything between two
points (or at least two releases), including PRs, content diff,
commits, closed issues, etc.; and being able to restrict it to
particular folders would be great.

[1] https://docs.github.com/en/repositories/releasing-projects-on-github/comparing-releases

Cheers,
Miguel

Re: [PATCH 3/3] rust: upgrade to Rust 1.68.2

[Gary Guo]

On Tue, 18 Apr 2023 23:43:47 +0200
Miguel Ojeda <ojeda@kernel.org> wrote:

> 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
> 3519c4d6e08e ("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: https://github.com/Rust-for-Linux/linux/issues/2 [2]
> Link: https://lore.kernel.org/rust-for-linux/CANiq72mT3bVDKdHgaea-6WiZazd8Mvurqmqegbe5JZxVyLR8Yg@mail.gmail.com/ [3]
> Link: https://github.com/rust-lang/rust/issues/106142 [4]
> Link: https://github.com/rust-lang/rust/pull/89891 [5]
> Link: https://github.com/rust-lang/rust/pull/98652 [6]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

I took this opportunity to re-review our diff with upstream alloc crate.

All the try_ series methods added to `Vec` and `RawVec` looks correct to
me.

Reviewed-by: Gary Guo <gary@garyguo.net>

> ---
>  Documentation/process/changes.rst |   2 +-
>  rust/alloc/alloc.rs               |  55 ++--
>  rust/alloc/boxed.rs               | 446 ++++++++++++++++++++++++++--
>  rust/alloc/collections/mod.rs     |   5 +-
>  rust/alloc/lib.rs                 |  71 +++--
>  rust/alloc/raw_vec.rs             |  16 +-
>  rust/alloc/slice.rs               | 447 ++++------------------------
>  rust/alloc/vec/drain.rs           |  81 +++++-
>  rust/alloc/vec/drain_filter.rs    |  60 +++-
>  rust/alloc/vec/into_iter.rs       | 125 ++++++--
>  rust/alloc/vec/is_zero.rs         |  96 ++++++-
>  rust/alloc/vec/mod.rs             | 464 +++++++++++++++++++++++-------
>  rust/alloc/vec/set_len_on_drop.rs |   5 +
>  rust/alloc/vec/spec_extend.rs     |  63 +---
>  rust/bindings/lib.rs              |   1 -
>  rust/kernel/build_assert.rs       |   2 +
>  rust/kernel/init.rs               |   5 +
>  rust/kernel/lib.rs                |   4 -
>  rust/kernel/std_vendor.rs         |   2 +
>  scripts/Makefile.build            |   2 +-
>  scripts/min-tool-version.sh       |   2 +-
>  21 files changed, 1274 insertions(+), 680 deletions(-)

Re: [PATCH 3/3] rust: upgrade to Rust 1.68.2

[Björn Roy Baron]

On Tuesday, April 18th, 2023 at 23:43, Miguel Ojeda <ojeda@kernel.org> wrote:

> 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
> 3519c4d6e08e ("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: https://github.com/Rust-for-Linux/linux/issues/2 [2]
> Link: https://lore.kernel.org/rust-for-linux/CANiq72mT3bVDKdHgaea-6WiZazd8Mvurqmqegbe5JZxVyLR8Yg@mail.gmail.com/ [3]
> Link: https://github.com/rust-lang/rust/issues/106142 [4]
> Link: https://github.com/rust-lang/rust/pull/89891 [5]
> Link: https://github.com/rust-lang/rust/pull/98652 [6]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>

> ---
>  Documentation/process/changes.rst |   2 +-
>  rust/alloc/alloc.rs               |  55 ++--
>  rust/alloc/boxed.rs               | 446 ++++++++++++++++++++++++++--
>  rust/alloc/collections/mod.rs     |   5 +-
>  rust/alloc/lib.rs                 |  71 +++--
>  rust/alloc/raw_vec.rs             |  16 +-
>  rust/alloc/slice.rs               | 447 ++++------------------------
>  rust/alloc/vec/drain.rs           |  81 +++++-
>  rust/alloc/vec/drain_filter.rs    |  60 +++-
>  rust/alloc/vec/into_iter.rs       | 125 ++++++--
>  rust/alloc/vec/is_zero.rs         |  96 ++++++-
>  rust/alloc/vec/mod.rs             | 464 +++++++++++++++++++++++-------
>  rust/alloc/vec/set_len_on_drop.rs |   5 +
>  rust/alloc/vec/spec_extend.rs     |  63 +---
>  rust/bindings/lib.rs              |   1 -
>  rust/kernel/build_assert.rs       |   2 +
>  rust/kernel/init.rs               |   5 +
>  rust/kernel/lib.rs                |   4 -
>  rust/kernel/std_vendor.rs         |   2 +
>  scripts/Makefile.build            |   2 +-
>  scripts/min-tool-version.sh       |   2 +-
>  21 files changed, 1274 insertions(+), 680 deletions(-)

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Boqun Feng]

On Tue, Apr 18, 2023 at 11:43:44PM +0200, Miguel Ojeda wrote:
> 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).
> 
> Please see the last patch message for a long explanation of the upgrade,
> the policy for future upgrades and some indications on how to easily
> review this.
> 
> The series is based on `rust-next`.
> 

Works on my machine ;-)

Tested-by: Boqun Feng <boqun.feng@gmail.com>

Regards,
Boqun

> Miguel Ojeda (3):
>   rust: alloc: clarify what is the upstream version
>   rust: arc: fix intra-doc link in `Arc<T>::init`
>   rust: upgrade to Rust 1.68.2
> 
>  Documentation/process/changes.rst |   2 +-
>  rust/alloc/README.md              |   3 +
>  rust/alloc/alloc.rs               |  55 ++--
>  rust/alloc/boxed.rs               | 446 ++++++++++++++++++++++++++--
>  rust/alloc/collections/mod.rs     |   5 +-
>  rust/alloc/lib.rs                 |  71 +++--
>  rust/alloc/raw_vec.rs             |  16 +-
>  rust/alloc/slice.rs               | 447 ++++------------------------
>  rust/alloc/vec/drain.rs           |  81 +++++-
>  rust/alloc/vec/drain_filter.rs    |  60 +++-
>  rust/alloc/vec/into_iter.rs       | 125 ++++++--
>  rust/alloc/vec/is_zero.rs         |  96 ++++++-
>  rust/alloc/vec/mod.rs             | 464 +++++++++++++++++++++++-------
>  rust/alloc/vec/set_len_on_drop.rs |   5 +
>  rust/alloc/vec/spec_extend.rs     |  63 +---
>  rust/bindings/lib.rs              |   1 -
>  rust/kernel/build_assert.rs       |   2 +
>  rust/kernel/init.rs               |   5 +
>  rust/kernel/lib.rs                |   4 -
>  rust/kernel/std_vendor.rs         |   2 +
>  rust/kernel/sync/arc.rs           |   2 +-
>  scripts/Makefile.build            |   2 +-
>  scripts/min-tool-version.sh       |   2 +-
>  23 files changed, 1278 insertions(+), 681 deletions(-)
> 
> -- 
> 2.40.0
> 

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[David Gow]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Wed, 19 Apr 2023 at 05:44, Miguel Ojeda <ojeda@kernel.org> wrote:
>
> 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).
>
> Please see the last patch message for a long explanation of the upgrade,
> the policy for future upgrades and some indications on how to easily
> review this.
>
> The series is based on `rust-next`.
>

Builds and runs fine under UML here, too.

Series is:
Tested-by: David Gow <davidgow@google.com>


Cheers,
-- David

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Ariel Miculas]

I've applied the patch series, upgraded rustc and built the kernel:

$ rustup override set $(scripts/min-tool-version.sh rustc)
$ rustup component add rust-src # Rust standard library source
$ cargo install --locked --version $(scripts/min-tool-version.sh
bindgen) bindgen
$ make LLVM=1 rustavailable
$ grep  RUSTC_VERSION .config
CONFIG_RUSTC_VERSION_TEXT="rustc 1.68.2 (9eb3afe9e 2023-03-27)"
$ make LLVM=1 -j$(nproc)

Then I ran the kernel in qemu-system-x86_64, inserted the
rust_minimal.ko kernel module and checked that it behaves as expected.

Tested-by: Ariel Miculas <amiculas@cisco.com>

Cheers,
Ariel

On Wed, Apr 19, 2023 at 12:48 AM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> 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).
>
> Please see the last patch message for a long explanation of the upgrade,
> the policy for future upgrades and some indications on how to easily
> review this.
>
> The series is based on `rust-next`.
>
> Miguel Ojeda (3):
>   rust: alloc: clarify what is the upstream version
>   rust: arc: fix intra-doc link in `Arc<T>::init`
>   rust: upgrade to Rust 1.68.2
>
>  Documentation/process/changes.rst |   2 +-
>  rust/alloc/README.md              |   3 +
>  rust/alloc/alloc.rs               |  55 ++--
>  rust/alloc/boxed.rs               | 446 ++++++++++++++++++++++++++--
>  rust/alloc/collections/mod.rs     |   5 +-
>  rust/alloc/lib.rs                 |  71 +++--
>  rust/alloc/raw_vec.rs             |  16 +-
>  rust/alloc/slice.rs               | 447 ++++------------------------
>  rust/alloc/vec/drain.rs           |  81 +++++-
>  rust/alloc/vec/drain_filter.rs    |  60 +++-
>  rust/alloc/vec/into_iter.rs       | 125 ++++++--
>  rust/alloc/vec/is_zero.rs         |  96 ++++++-
>  rust/alloc/vec/mod.rs             | 464 +++++++++++++++++++++++-------
>  rust/alloc/vec/set_len_on_drop.rs |   5 +
>  rust/alloc/vec/spec_extend.rs     |  63 +---
>  rust/bindings/lib.rs              |   1 -
>  rust/kernel/build_assert.rs       |   2 +
>  rust/kernel/init.rs               |   5 +
>  rust/kernel/lib.rs                |   4 -
>  rust/kernel/std_vendor.rs         |   2 +
>  rust/kernel/sync/arc.rs           |   2 +-
>  scripts/Makefile.build            |   2 +-
>  scripts/min-tool-version.sh       |   2 +-
>  23 files changed, 1278 insertions(+), 681 deletions(-)
>
> --
> 2.40.0
>

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Miguel Ojeda]

On Thu, Apr 20, 2023 at 3:13 PM Ariel Miculas <ariel.miculas@gmail.com> wrote:
>
> $ make LLVM=1 rustavailable

Since you showed the output of the other commands, did this one show
"Rust is available!"? I guess so -- I imagine you edited the commands
for the email, e.g. the config changed too.

That is fine, as long as it works as expected :) Thanks a lot for testing!

Cheers,
Miguel

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Ariel Miculas]

Yes, I've edited the commands since I've run them out of order, let me
include the output of commands and my general setup.
Since I've already run these steps previously, most of the commands
just say that it's already configured.

❯ rustup override set $(scripts/min-tool-version.sh rustc)
info: using existing install for '1.68.2-x86_64-unknown-linux-gnu'
info: override toolchain for '/home/amiculas/work/linux' set to
'1.68.2-x86_64-unknown-linux-gnu'

  1.68.2-x86_64-unknown-linux-gnu unchanged - rustc 1.68.2 (9eb3afe9e
2023-03-27)

❯ rustup override list
/home/amiculas/work/linux                       1.68.2-x86_64-unknown-linux-gnu

❯ rustup component add rust-src
info: component 'rust-src' is up to date

❯ cargo install --locked --version $(scripts/min-tool-version.sh
bindgen) bindgen
     Ignored package `bindgen v0.56.0` is already installed, use
--force to override

❯  make LLVM=1 rustavailable
Rust is available!

❮ rg -i '[^a-zA-Z]rust' .config
14:CONFIG_RUST_IS_AVAILABLE=y
279:CONFIG_RUST=y
280:CONFIG_RUSTC_VERSION_TEXT="rustc 1.68.2 (9eb3afe9e 2023-03-27)"
687:CONFIG_HAVE_RUST=y
5093:CONFIG_SAMPLES_RUST=y
5094:CONFIG_SAMPLE_RUST_MINIMAL=m
5095:CONFIG_SAMPLE_RUST_PRINT=m
5096:CONFIG_SAMPLE_RUST_HOSTPROGS=y
5185:# Rust hacking
5187:# CONFIG_RUST_DEBUG_ASSERTIONS is not set
5188:CONFIG_RUST_OVERFLOW_CHECKS=y
5189:# CONFIG_RUST_BUILD_ASSERT_ALLOW is not set
5190:# end of Rust hacking

❯ make LLVM=1 -j$(nproc)
  DESCEND objtool
  CALL    scripts/checksyscalls.sh
make[3]: 'install_headers' is up to date.
grep: warning: stray \ before #
grep: warning: stray \ before #
Kernel: arch/x86/boot/bzImage is ready  (#29)

# I have some commits on top of the patchset, but they are only for
setting up the kernel environment (an initramfs with busybox, running
inside qemu)
❯ git log --oneline
03cad1754b24 (HEAD -> ariel-rust) Add lwnfs.ko kernel module to initramfs
233183beae92 Insert rust_fs.ko module and mount a rustfs to /mnt
a1de6ad1ec15 Add other rust samples to initramfs
192ab4a5dd58 Mount /dev, /proc and insert the parrot.ko module
05d7232d50cf enable kvm
c2724fa122af Add scripts for running the kernel in qemu
3f81af042dd2 (rust-next) rust: upgrade to Rust 1.68.2
418e1087dce1 rust: arc: fix intra-doc link in `Arc<T>::init`
ee16705fb79f rust: alloc: clarify what is the upstream version
1944caa8e8dc (rust-for-linux/rust-next) rust: sync: add functions for
initializing `UniqueArc<MaybeUninit<T>>`
701608bd030a rust: sync: reduce stack usage of `UniqueArc::try_new_uninit`
692e8935e23e rust: types: add `Opaque::ffi_init`

❯ git --no-pager diff
diff --git a/samples/rust/rust_minimal.rs b/samples/rust/rust_minimal.rs
index dc05f4bbe27e..1ca75c85f161 100644
--- a/samples/rust/rust_minimal.rs
+++ b/samples/rust/rust_minimal.rs
@@ -19,6 +19,7 @@ struct RustMinimal {
 impl kernel::Module for RustMinimal {
     fn init(_module: &'static ThisModule) -> Result<Self> {
         pr_info!("Rust minimal sample (init)\n");
+        pr_info!("Ariel was here");
         pr_info!("Am I built-in? {}\n", !cfg!(MODULE));

         let mut numbers = Vec::new();

❯ cd linux-environment
❯ ls
busybox  Makefile  qemu-initramfs.desc  qemu-initramfs.img
qemu-init.sh  run_qemu.sh

❯ file busybox
busybox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, stripped

❯ /usr/bin/cat Makefile
.PHONY: all clean

all: qemu-initramfs.img

qemu-initramfs.img:
        ../usr/gen_init_cpio qemu-initramfs.desc > qemu-initramfs.img

clean:
        rm qemu-initramfs.img

run: qemu-initramfs.img
        sudo ./run_qemu.sh

❯ /usr/bin/cat qemu-init.sh
#!/bin/sh

busybox mount -t devtmpfs none /dev
busybox mount -t proc none /proc
busybox mount -t sysfs none /sys

busybox insmod rust_minimal.ko
busybox rmmod rust_minimal.ko
busybox setsid sh -c 'exec sh -l </dev/ttyS0 >/dev/ttyS0 2>&1'

❯ /usr/bin/cat qemu-initramfs.desc
dir     /bin                                          0755 0 0
dir     /sys                                          0755 0 0
dir     /dev                                          0755 0 0
dir     /proc                                         0755 0 0
file    /bin/busybox  busybox                         0755 0 0
slink   /bin/sh       /bin/busybox                    0755 0 0
file    /init         qemu-init.sh                    0755 0 0

file    /rust_minimal.ko            ../samples/rust/rust_minimal.ko
        0755 0 0
file    /rust_print.ko              ../samples/rust/rust_print.ko
        0755 0 0

❯ make
../usr/gen_init_cpio qemu-initramfs.desc > qemu-initramfs.img

❯ /usr/bin/cat run_qemu.sh
sudo qemu-system-x86_64 \
    -kernel ../arch/x86/boot/bzImage \
    -initrd qemu-initramfs.img \
    -M pc \
    -m 4G \
    -accel kvm \
    -cpu host \
    -smp $(nproc) \
    -nographic \
    -vga none \
    -no-reboot \
    -append 'console=ttyS0'

❯ ./run_qemu.sh
[sudo] password for amiculas:
SeaBIOS (version Arch Linux 1.16.2-1-1)


iPXE (http://ipxe.org) 00:02.0 C000 PCI2.10 PnP PMM+BEFD31B0+BEF331B0 C000



Booting from ROM..
[    0.000000] Linux version 6.3.0-rc6-00039-g03cad1754b24-dirty
(amiculas@archlinux-cisco) (clang version 15.0.7, LLD 15.0.7) #29 SMP
PREEMPT_DYNAMIC Thu Apr 20 15:54:18 EEST 2023
[    0.000000] Command line: console=ttyS0
...
[    0.802414] Run /init as init process
[    0.803185] busybox (89) used greatest stack depth: 13848 bytes left
[    0.805450] rust_minimal: Rust minimal sample (init)
[    0.805736] rust_minimal: Ariel was here
[    0.805737] rust_minimal: Am I built-in? false
[    0.806304] busybox (92) used greatest stack depth: 13696 bytes left
[    0.806591] rust_minimal: My numbers are [72, 108, 200]
[    0.807021] rust_minimal: Rust minimal sample (exit)

Cheers,
Ariel

On Thu, Apr 20, 2023 at 4:20 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Apr 20, 2023 at 3:13 PM Ariel Miculas <ariel.miculas@gmail.com> wrote:
> >
> > $ make LLVM=1 rustavailable
>
> Since you showed the output of the other commands, did this one show
> "Rust is available!"? I guess so -- I imagine you edited the commands
> for the email, e.g. the config changed too.
>
> That is fine, as long as it works as expected :) Thanks a lot for testing!
>
> Cheers,
> Miguel

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Miguel Ojeda]

On Thu, Apr 20, 2023 at 7:18 PM Ariel Miculas <ariel.miculas@gmail.com> wrote:
>
> Yes, I've edited the commands since I've run them out of order, let me
> include the output of commands and my general setup.

Thanks for confirming! (and for all the output!).

Cheers,
Miguel

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Fabien Parent]

Hi Miguel,

I'm getting the following error when running rusttest on top of your patchset:

$ make LLVM=1 RUSTC=/home/fparent/.rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/bin/rustc
RUSTDOC=/home/fparent/.rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/bin/rustdoc
rusttest
  RUSTC L rust/uapi.o
error: the feature `core_ffi_c` has been stable since 1.64.0 and no
longer requires an attribute to enable
  --> rust/uapi/lib.rs:11:12
   |
11 | #![feature(core_ffi_c)]
   |            ^^^^^^^^^^

After manually removing line 11 in lib.rs, the error was gone.

Fabien

On Thu, 20 Apr 2023 at 19:20, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Apr 20, 2023 at 7:18 PM Ariel Miculas <ariel.miculas@gmail.com> wrote:
> >
> > Yes, I've edited the commands since I've run them out of order, let me
> > include the output of commands and my general setup.
>
> Thanks for confirming! (and for all the output!).
>
> Cheers,
> Miguel

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Miguel Ojeda]

Hi Fabien,

On Fri, May 5, 2023 at 12:28 AM Fabien Parent <fabien.parent@linaro.org> wrote:
>
> I'm getting the following error when running rusttest on top of your patchset:

Yeah, it is expected: the series was based on `rust-next` which gained
the `uapi` crate later on.

Thanks for reporting it!

Cheers,
Miguel

Re: [PATCH 0/3] Rust 1.68.2 upgrade

[Miguel Ojeda]

On Tue, Apr 18, 2023 at 11:44 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> 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).
>
> Please see the last patch message for a long explanation of the upgrade,
> the policy for future upgrades and some indications on how to easily
> review this.
>
> The series is based on `rust-next`.

Applied to `rust-next` (with the `core_ffi_c` removal in the `uapi` crate).

Thanks a lot to all reviewers and testers (and thanks Gary for
re-reviewing our diff with respect to upstream `alloc`).

Cheers,
Miguel