Received-SPF: pass (google.com: domain of linux-kernel+bounces-131137-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 04 Apr 2024 08:53:22 +0000
To: Boqun Feng <boqun.feng@gmail.com>
From: Benno Lossin <benno.lossin@proton.me>
Cc: Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@gmail.com>, Gary Guo <gary@garyguo.net>, =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, Andreas Hindborg <a.hindborg@samsung.com>, Alice Ryhl <aliceryhl@google.com>, Martin Rodriguez Reboredo <yakoyoku@gmail.com>, 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: <331cfa9d-9687-4922-a7f8-5579173d66c0@proton.me>
In-Reply-To: <Zg3aVLUHkRFxqAh3@boqun-archlinux>
References: <20240403194321.88716-1-benno.lossin@proton.me> <Zg3IHZfYVEOh7nc4@boqun-archlinux> <ef1400ae-ba9e-4656-98db-a882ac720c1e@proton.me> <Zg3aVLUHkRFxqAh3@boqun-archlinux>
Feedback-ID: 71780778:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 04.04.24 00:38, Boqun Feng wrote:
> On Wed, Apr 03, 2024 at 10:09:49PM +0000, Benno Lossin wrote:
>> 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
> Ok, so a new binding cannot shadow the name of a constant, that's a bit
> surprising, but seems makes sense.
>=20
> The solution is not ideal (for example, a constant can have the name
> "__something_guard"), but nothing better we could I guess.

Yeah that would also be problematic. I think the problem from the thread
is best solved by making the constant there upper case, so it would also
avoid this issue.
But debugging the error in the macro is a bit annoying, so if someone
encounters this again, they don't have to deal with that.

--=20
Cheers,
Benno