Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7360437rwb; Tue, 6 Dec 2022 04:57:50 -0800 (PST) X-Google-Smtp-Source: AA0mqf74nDvK2EAjVMl7UH1XfmeX/L0FXbPZ8Xk9G70YGli6qv/+0Kmvw6TAqmDnRN6A9N9rUyYU X-Received: by 2002:a17:90b:1d43:b0:219:dd76:7e87 with SMTP id ok3-20020a17090b1d4300b00219dd767e87mr8553199pjb.233.1670331470414; Tue, 06 Dec 2022 04:57:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670331470; cv=none; d=google.com; s=arc-20160816; b=enNrOMV85iUnc3ih1CD5LHK7Pr6BEBAT1SL7cwQzLMVRjLaC4lcaDuK3jGvlLrm0lt cLF5Or77bXHov7JVIVX4qCW9FsKrBApHTPR7UEa+0zoh7YdPNEKwgXPARGwBgG5jZ6qV GKCP88ww/pa4sj65GbQCNc6iwCGxLVq7GLfEvu4ps6K799Gzz2uTlV8rqrwkTvAQp0LN 65eebVD5SdltQJnu5zusFADrH17H0blQsyhgBqmqN1TzQ3hUSQ+W4HTAQrvs7Vi1eDkM eCRT7EN9LmAdAZNqh89GhwNNAUyBIIh2RaLKadg+IGRhm1DVNDi3Xk8JcrcoBgYavAEx xt7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=B36lQzGmc6BirP+Aeg4Xr0DaY4W4N99CzPG3/BD5qhQ=; b=YeOZ/HBdPUhV1h2hMgBMXkavHsBG6jlRuL/BFboV2KbDxKLSe0L7PBZ/1ZBbJYbo4T HXbjXYWQu6aUfU03ZqnMvm6KkAGRy10jSrGKIQq556a1hYpNBP8XjO1qIieb3AC6YKSb R0GAy3JPNJL5mqfCYjGBYzmc5uowtoNRHhzXx6ugDhFfmWcryUhPrcIa/oszbtoLa3Lq VKextpJ0dZEQ7Ib49o1lBrP1nA2DhqyiKHtUAmC4XTadsU5va8Sbc3v0z18agQWyh8UX 8j1ZTy5GxV+gV+3zHa7XTQDU3NG5wvI7q6lq356TkMsDe/oqDvPi2lVU0Ozfiwe5m1KF ExHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nyantec.com header.s=default header.b=J1qhPzQI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=nyantec.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 17-20020a170902e9d100b0018867e3182esi16413265plk.335.2022.12.06.04.57.39; Tue, 06 Dec 2022 04:57:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@nyantec.com header.s=default header.b=J1qhPzQI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=nyantec.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234637AbiLFM4c (ORCPT + 80 others); Tue, 6 Dec 2022 07:56:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234763AbiLFM4P (ORCPT ); Tue, 6 Dec 2022 07:56:15 -0500 X-Greylist: delayed 228 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 06 Dec 2022 04:56:11 PST Received: from mout-b-203.mailbox.org (mout-b-203.mailbox.org [IPv6:2001:67c:2050:102:465::203]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CCEBD2BF5; Tue, 6 Dec 2022 04:56:10 -0800 (PST) Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-203.mailbox.org (Postfix) with ESMTPS id 4NRL4y2jrpz9tK5; Tue, 6 Dec 2022 13:56:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nyantec.com; s=default; t=1670331362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=B36lQzGmc6BirP+Aeg4Xr0DaY4W4N99CzPG3/BD5qhQ=; b=J1qhPzQIXfZuykmFyrDwkLOaP/fmRoxe6VH2lc7U1Xp00zV4CgZ1Oz1Eovof+apvXVR5+/ /4G31hK5ivNOG6P5fO3P2cNXB2glL6rgcrd+y3GIbqKtT7iVrOak9XebSdXylkR/pGIWPq PPuPEq0OtSUZO1VLZ3Y1YzkMDGEg2kgbs2tM1AnK/CjAAd1mY+HyCVTDoYUrm12b16g7Lr b7hKYhpBtN3/qjmmDg6w05xOHCAfQ+M+LU9kqP1f5il51eUqgLNHKDwfxUZe8YOiIMYu70 CqGtfR7lxElyNdV3FD0jZcNwyjA06b0dIXJjwbNeoqNv9Qz3YQN0HXDz3G9O+A== From: Finn Behrens To: ojeda@kernel.org Cc: Wedson Almeida Filho , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev Subject: Re: [PATCH v2 13/28] rust: alloc: add `Vec::try_with_capacity{,_in}()` constructors Date: Tue, 06 Dec 2022 13:55:56 +0100 Message-ID: In-Reply-To: <20221202161502.385525-14-ojeda@kernel.org> References: <20221202161502.385525-1-ojeda@kernel.org> <20221202161502.385525-14-ojeda@kernel.org> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2 Dec 2022, at 17:14, ojeda@kernel.org wrote: > From: Miguel Ojeda > > Add `Vec::try_with_capacity()` and `Vec::try_with_capacity_in()` as > the fallible versions of `Vec::with_capacity()` and > `Vec::with_capacity_in()`, respectively. > > The implementations follow the originals and use the previously > added `RawVec::try_with_capacity_in()`. > > In turn, `Vec::try_with_capacity()` will be used to implement > the `CString` type (which wraps a `Vec`) in a later patch. > > Reviewed-by: Gary Guo > Signed-off-by: Miguel Ojeda Reviewed-by: Finn Behrens Regards, Finn > --- > rust/alloc/raw_vec.rs | 1 - > rust/alloc/vec/mod.rs | 89 +++++++++++++++++++++++++++++++++++++++++++= > 2 files changed, 89 insertions(+), 1 deletion(-) > > diff --git a/rust/alloc/raw_vec.rs b/rust/alloc/raw_vec.rs > index c342f3843972..eb77db5def55 100644 > --- a/rust/alloc/raw_vec.rs > +++ b/rust/alloc/raw_vec.rs > @@ -135,7 +135,6 @@ impl RawVec { > > /// Like `try_with_capacity`, but parameterized over the choice of= > /// allocator for the returned `RawVec`. > - #[allow(dead_code)] > #[inline] > pub fn try_with_capacity_in(capacity: usize, alloc: A) -> Result { > Self::try_allocate_in(capacity, AllocInit::Uninitialized, allo= c) > diff --git a/rust/alloc/vec/mod.rs b/rust/alloc/vec/mod.rs > index 540787804cc2..8ac6c1e3b2a8 100644 > --- a/rust/alloc/vec/mod.rs > +++ b/rust/alloc/vec/mod.rs > @@ -472,6 +472,48 @@ impl Vec { > Self::with_capacity_in(capacity, Global) > } > > + /// Tries to construct a new, empty `Vec` with the specified ca= pacity. > + /// > + /// The vector will be able to hold exactly `capacity` elements wi= thout > + /// reallocating. If `capacity` is 0, the vector will not allocate= =2E > + /// > + /// It is important to note that although the returned vector has = the > + /// *capacity* specified, the vector will have a zero *length*. Fo= r an > + /// explanation of the difference between length and capacity, see= > + /// *[Capacity and reallocation]*. > + /// > + /// [Capacity and reallocation]: #capacity-and-reallocation > + /// > + /// # Examples > + /// > + /// ``` > + /// let mut vec =3D Vec::try_with_capacity(10).unwrap(); > + /// > + /// // The vector contains no items, even though it has capacity f= or more > + /// assert_eq!(vec.len(), 0); > + /// assert_eq!(vec.capacity(), 10); > + /// > + /// // These are all done without reallocating... > + /// for i in 0..10 { > + /// vec.push(i); > + /// } > + /// assert_eq!(vec.len(), 10); > + /// assert_eq!(vec.capacity(), 10); > + /// > + /// // ...but this may make the vector reallocate > + /// vec.push(11); > + /// assert_eq!(vec.len(), 11); > + /// assert!(vec.capacity() >=3D 11); > + /// > + /// let mut result =3D Vec::try_with_capacity(usize::MAX); > + /// assert!(result.is_err()); > + /// ``` > + #[inline] > + #[stable(feature =3D "kernel", since =3D "1.0.0")] > + pub fn try_with_capacity(capacity: usize) -> Result { > + Self::try_with_capacity_in(capacity, Global) > + } > + > /// Creates a `Vec` directly from the raw components of another= vector. > /// > /// # Safety > @@ -617,6 +659,53 @@ impl Vec { > Vec { buf: RawVec::with_capacity_in(capacity, alloc), len: 0 }= > } > > + /// Tries to construct a new, empty `Vec` with the specified= capacity > + /// with the provided allocator. > + /// > + /// The vector will be able to hold exactly `capacity` elements wi= thout > + /// reallocating. If `capacity` is 0, the vector will not allocate= =2E > + /// > + /// It is important to note that although the returned vector has = the > + /// *capacity* specified, the vector will have a zero *length*. Fo= r an > + /// explanation of the difference between length and capacity, see= > + /// *[Capacity and reallocation]*. > + /// > + /// [Capacity and reallocation]: #capacity-and-reallocation > + /// > + /// # Examples > + /// > + /// ``` > + /// #![feature(allocator_api)] > + /// > + /// use std::alloc::System; > + /// > + /// let mut vec =3D Vec::try_with_capacity_in(10, System).unwrap()= ; > + /// > + /// // The vector contains no items, even though it has capacity f= or more > + /// assert_eq!(vec.len(), 0); > + /// assert_eq!(vec.capacity(), 10); > + /// > + /// // These are all done without reallocating... > + /// for i in 0..10 { > + /// vec.push(i); > + /// } > + /// assert_eq!(vec.len(), 10); > + /// assert_eq!(vec.capacity(), 10); > + /// > + /// // ...but this may make the vector reallocate > + /// vec.push(11); > + /// assert_eq!(vec.len(), 11); > + /// assert!(vec.capacity() >=3D 11); > + /// > + /// let mut result =3D Vec::try_with_capacity_in(usize::MAX, Syste= m); > + /// assert!(result.is_err()); > + /// ``` > + #[inline] > + #[stable(feature =3D "kernel", since =3D "1.0.0")] > + pub fn try_with_capacity_in(capacity: usize, alloc: A) -> Result { > + Ok(Vec { buf: RawVec::try_with_capacity_in(capacity, alloc)?, = len: 0 }) > + } > + > /// Creates a `Vec` directly from the raw components of anot= her vector. > /// > /// # Safety > -- = > 2.38.1