From patchwork Fri Dec 2 16:14:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miguel Ojeda X-Patchwork-Id: 28968 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp947819wrr; Fri, 2 Dec 2022 08:18:35 -0800 (PST) X-Google-Smtp-Source: AA0mqf4GotR4uGzalRSsqm0g3ZY058eQXl+hiB/jITGybNS3JfSirFCvBWVD/PzLV2HeMpxQfe6V X-Received: by 2002:aa7:c2d6:0:b0:46c:38a4:a54c with SMTP id m22-20020aa7c2d6000000b0046c38a4a54cmr2480525edp.393.1669997915823; Fri, 02 Dec 2022 08:18:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669997915; cv=none; d=google.com; s=arc-20160816; b=PxpUNDb0id4uTdbHziNBTrIiriy+OI0HDcSvFHLri9t068lTqtBBzETlPWFLVIrX85 KK5Nuc1mp0nuii9jsPdNiJLiL0BvxM23yojVSE0F1kJZP91Z1/+VB1stJfZBz78jeZw6 EmraHaFaTZasKa08dFGU/+v7tcwpugCiQewY0Z2jONi4cUwOCK+Qcst9HD6sOTuqTeK9 6Egihd+NIcgtvNyOXwPyHJkLbFWDvtUTvPqxeEn/JPlhBpik2FieJzL4ydSdBGRWmFGO plJiAB/qE/fVwQW5ZUt1zezpBmV9D9p6Ks+j13O27xtHlPh6AkjdTEBZry2x2gqPrUEa wRlQ== 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=xNUDI3Zu8DgTqPldgTIuf8eJlS/9XRTq9TOIImrKYzc=; b=FlhO4us+3ajVOHqgWi1AE0UUC6XU/0lxV+4lVRRZo+Ab5/w8wJdNmNVfTjjc58jVEe aeHoiZnWUxElxWJ+7VCttXlNBmHUwQnRLV5iOgkFjSH6IRKMrquWsZsWnV9PXd9eDXg7 gsPs4CLYSv18ZbTRDlCOlF2Ja+EjzGFexl3MsmzoV+gcxMI+xXeOmt+hvySQaag9vbCC jfU2jlWUdOdwkB2qYiR3b+zNTpL9sX+gXJo1uLlmJ3bN9xgfyEUyFUS3JxiysWgAZ6rR 2Y96bmj/eMPzRgX7l2oK/l1R6HlfRaHECYkC+o0NMOL8UKn/aiquaBYo0xGRjes3etEN WoYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=eZzKRlTs; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hp12-20020a1709073e0c00b007c07f7713d7si7721558ejc.99.2022.12.02.08.18.10; Fri, 02 Dec 2022 08:18:35 -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=@kernel.org header.s=k20201202 header.b=eZzKRlTs; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233677AbiLBQRJ (ORCPT + 99 others); Fri, 2 Dec 2022 11:17:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233975AbiLBQQa (ORCPT ); Fri, 2 Dec 2022 11:16:30 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 075DAD208B; Fri, 2 Dec 2022 08:16:07 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D90E562331; Fri, 2 Dec 2022 16:16:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23525C43470; Fri, 2 Dec 2022 16:16:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669997766; bh=2kl4siMs2CiGNBXEZpLt5Bkk+dmVvKDxrC3ndkxJ8nE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eZzKRlTsLe+l4byy89diKfAYGW9gr1GxcrGfLMdowMTdFbapJswUpLyrVVyMFWbo8 nhk0YPlJgcqDriXywi2C7Zw8JuJ0jh9n7KlBk6lAjjY9uWjuYyugHjwLAYWpfCIy2p tb8LNf6EKbYFWQ4GBZheYuFM8j945A3k55dDEBHfKG2vylvqpfjaMlfnaUxPIHLiI/ r8xdzY2y2mmB0jH2VK+lP7AaSoB3Emt3gw5hdKF0ljfbx1QY+S7hYHofcUgW20htQo Dkx3NcXamstan9FGeYI+3ZA1htUUU0U3DA9f54Bgu+5XX29VRgOHHQBkbLctLQGDJC ugz2s0P5LHqXg== From: ojeda@kernel.org To: Miguel Ojeda , Wedson Almeida Filho , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev Subject: [PATCH v2 13/28] rust: alloc: add `Vec::try_with_capacity{,_in}()` constructors Date: Fri, 2 Dec 2022 17:14:44 +0100 Message-Id: <20221202161502.385525-14-ojeda@kernel.org> In-Reply-To: <20221202161502.385525-1-ojeda@kernel.org> References: <20221202161502.385525-1-ojeda@kernel.org> MIME-Version: 1.0 X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751119734865434690?= X-GMAIL-MSGID: =?utf-8?q?1751119734865434690?= 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 --- 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, alloc) 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 capacity. + /// + /// The vector will be able to hold exactly `capacity` elements without + /// reallocating. If `capacity` is 0, the vector will not allocate. + /// + /// It is important to note that although the returned vector has the + /// *capacity* specified, the vector will have a zero *length*. For an + /// explanation of the difference between length and capacity, see + /// *[Capacity and reallocation]*. + /// + /// [Capacity and reallocation]: #capacity-and-reallocation + /// + /// # Examples + /// + /// ``` + /// let mut vec = Vec::try_with_capacity(10).unwrap(); + /// + /// // The vector contains no items, even though it has capacity for 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() >= 11); + /// + /// let mut result = Vec::try_with_capacity(usize::MAX); + /// assert!(result.is_err()); + /// ``` + #[inline] + #[stable(feature = "kernel", since = "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 without + /// reallocating. If `capacity` is 0, the vector will not allocate. + /// + /// It is important to note that although the returned vector has the + /// *capacity* specified, the vector will have a zero *length*. For 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 = Vec::try_with_capacity_in(10, System).unwrap(); + /// + /// // The vector contains no items, even though it has capacity for 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() >= 11); + /// + /// let mut result = Vec::try_with_capacity_in(usize::MAX, System); + /// assert!(result.is_err()); + /// ``` + #[inline] + #[stable(feature = "kernel", since = "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 another vector. /// /// # Safety