lkml.org 
[lkml]   [2024]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] rust: init: change the generated name of guard variables
On 17.04.24 17:06, Gary Guo wrote:
> On Wed, 03 Apr 2024 22:09:49 +0000
> Benno Lossin <benno.lossin@proton.me> 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-705a9cbb1627@proton.me/
>>
>
> Here's the simplified example:
>
> ```
> macro_rules! f {
> () => {
> let a = 1;
> let _: u32 = a;
> }
> }
>
> const a: u64 = 1;
>
> fn main() {
> f!();
> }
> ```
>
> 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.
>
> 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/compile-fail

--
Cheers,
Benno


\
 
 \ /
  Last update: 2024-04-17 17:21    [W:0.460 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site