Messages in this thread | | | Date | Wed, 17 Apr 2024 15:20:37 +0000 | From | Benno Lossin <> | Subject | Re: [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
| |