From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC2411422BE for ; Wed, 17 Apr 2024 15:20:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.134 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713367252; cv=none; b=itS1JNGHm09WdsaXj8Eh3PpeOfu3fKmANhWVUPbQuxN6ZZ6Ljn5e8LJc4HquTKDkta1BPALpQX82cZ85PkhE0phdYZCsXy70K4PuBnetDcNe7AyUjfxNJ6dhclscS6WfpiD6EUxZ26RazYWwvVemXn/lYSh89+wZIE+GJ5/RSuY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713367252; c=relaxed/simple; bh=UPBih86VwhYA999zRYFTWuXSTMQT7D7fNy+bP56pCiA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uTzA4O7AUt2/M0whibGRxD8oyYHiqsAIz8Nddi4+c/0Hp5X1T+nUjtBi3JyDm9r2fQFzciukq7Br4FPtx/ZdYhu+5EzLMnyNc0Oa+oFlViurvNrQb3lzAeB2mmcc+VdAWqKs2H1qvGcW2FsEWRbgFfh4n8kEUyxvb9iUpvcLJXM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=hmZWA4cy; arc=none smtp.client-ip=185.70.40.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="hmZWA4cy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1713367248; x=1713626448; bh=YWyxuaF5Ni3EMSqmk2O91LAhe4Gw3wdUrmkeI2YFMFo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hmZWA4cy+e2OIIPIyuSEmU3oRMgzgatK5jfeklNaNCTWZ4Cuh2lDy2gxdszV2K+hQ gCCil2rQq9I6zl/M/J6NRT8GcUd+IZS0bIAgVCKnYUD5O0UHMpkYVIcZULKJc5e9Oq LkylIL2rKrnN6sLH9q6DW42YajeJU62UBzfUyt/VGgFktfGVcPipH3ASrFQfHrt52a KjUR/o9Y01NDsYemSrBdpiRmESEKiTNDcDXhR4J0wS6VcBmtgNBhcjgb0VaIVhopg3 SoUwNym0BkUtmIWxhjwKm2TdOTB4mafz2MYC5NVAUsP/eVTvQA6O2IzrdD85FdsExt lkzUynDPJc1Zw== Date: Wed, 17 Apr 2024 15:20:37 +0000 To: Gary Guo From: Benno Lossin Cc: Boqun Feng , Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Alice Ryhl , Martin Rodriguez Reboredo , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] rust: init: change the generated name of guard variables Message-ID: In-Reply-To: <20240417160636.0e649b68@eugeo> References: <20240403194321.88716-1-benno.lossin@proton.me> <20240417160636.0e649b68@eugeo> Feedback-ID: 71780778:user:proton Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17.04.24 17:06, Gary Guo wrote: > On Wed, 03 Apr 2024 22:09:49 +0000 > Benno Lossin wrote: >=20 >> On 03.04.24 23:20, Boqun Feng wrote: >>> On Wed, Apr 03, 2024 at 07:43:37PM +0000, Benno Lossin wrote: >>>> The initializers created by the `[try_][pin_]init!` macros utilize the >>>> guard pattern to drop already initialized fields, when initialization >>>> fails mid-way. These guards are generated to have the same name as the >>>> field that they handle. To prevent namespacing issues when the field >>> >>> Do you have an example of this kind of issues? >> >> https://lore.kernel.org/rust-for-linux/1e8a2a1f-abbf-44ba-8344-705a9cbb1= 627@proton.me/ >> >=20 > Here's the simplified example: >=20 > ``` > macro_rules! f { > () =3D> { > let a =3D 1; > let _: u32 =3D a; > } > } >=20 > const a: u64 =3D 1; >=20 > fn main() { > f!(); > } > ``` >=20 > The `a` in `f` have a different hygiene so normally it is scoped to the > macro expansion and wouldn't escape. Interestingly a constant is still > preferred despite the hygiene so constants escaped into the macro, > leading to the error. >=20 > Would your change regress error message when `pin_init!` is used > wrongly? Personally I would say this kind of error is niche enough > (given the casing of constants and variables differ) that we probably > don't really need to care. So if error message would be affected then > we'd better off not making the change. For all the tested error messages (see [1]) there is absolutely no difference in the diagnostic. [1]: https://github.com/Rust-for-Linux/pinned-init/tree/main/tests/ui/compi= le-fail --=20 Cheers, Benno