[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cafb786e-5f7a-489f-8d1b-443f761e10ec@proton.me>
Date: Thu, 26 Sep 2024 13:53:19 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Danilo Krummrich <dakr@...nel.org>, ojeda@...nel.org, alex.gaynor@...il.com, wedsonaf@...il.com, boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, a.hindborg@...sung.com, aliceryhl@...gle.com, akpm@...ux-foundation.org
Cc: daniel.almeida@...labora.com, faith.ekstrand@...labora.com, boris.brezillon@...labora.com, lina@...hilina.net, mcanal@...lia.com, zhiw@...dia.com, cjia@...dia.com, jhubbard@...dia.com, airlied@...hat.com, ajanulgu@...hat.com, lyude@...hat.com, linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v7 14/26] rust: alloc: implement `IntoIterator` for `Vec`
On 12.09.24 00:52, Danilo Krummrich wrote:
> Implement `IntoIterator` for `Vec`, `Vec`'s `IntoIter` type, as well as
> `Iterator` for `IntoIter`.
>
> `Vec::into_iter` disassembles the `Vec` into its raw parts; additionally,
> `IntoIter` keeps track of a separate pointer, which is incremented
> correspondingsly as the iterator advances, while the length, or the count
> of elements, is decremented.
>
> This also means that `IntoIter` takes the ownership of the backing
> buffer and is responsible to drop the remaining elements and free the
> backing buffer, if it's dropped.
>
> Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>
> Signed-off-by: Danilo Krummrich <dakr@...nel.org>
> ---
> rust/kernel/alloc.rs | 1 +
> rust/kernel/alloc/kvec.rs | 181 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 182 insertions(+)
One comment below, with that fixed:
Reviewed-by: Benno Lossin <benno.lossin@...ton.me>
---
Cheers,
Benno
> +impl<T, A> IntoIterator for Vec<T, A>
> +where
> + A: Allocator,
> +{
> + type Item = T;
> + type IntoIter = IntoIter<T, A>;
> +
> + /// Consumes the `Vec<T, A>` and creates an `Iterator`, which moves each value out of the
> + /// vector (from start to end).
> + ///
> + /// # Examples
> + ///
> + /// ```
> + /// let v = kernel::kvec![1, 2]?;
> + /// let mut v_iter = v.into_iter();
> + ///
> + /// let first_element: Option<u32> = v_iter.next();
> + ///
> + /// assert_eq!(first_element, Some(1));
> + /// assert_eq!(v_iter.next(), Some(2));
> + /// assert_eq!(v_iter.next(), None);
> + ///
> + /// # Ok::<(), Error>(())
> + /// ```
> + ///
> + /// ```
> + /// let v = kernel::kvec![];
> + /// let mut v_iter = v.into_iter();
> + ///
> + /// let first_element: Option<u32> = v_iter.next();
> + ///
> + /// assert_eq!(first_element, None);
> + ///
> + /// # Ok::<(), Error>(())
> + /// ```
> + #[inline]
> + fn into_iter(self) -> Self::IntoIter {
> + let (ptr, len, cap) = self.into_raw_parts();
> +
> + IntoIter {
> + ptr,
> + // SAFETY: `ptr` is either a dangling pointer or a pointer to a valid memory
> + // allocation, allocated with `A`.
> + buf: unsafe { NonNull::new_unchecked(ptr) },
Instead of this `unsafe` call, you can do
let buf = self.ptr;
Before the call to `into_raw_parts`.
> + len,
> + cap,
> + _p: PhantomData::<A>,
> + }
> + }
> +}
> --
> 2.46.0
>
Powered by blists - more mailing lists