linux-kernel - Re: [PATCH v2 08/12] rust: init: add support for arbitrary paths in init macros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230720133005.3545184-1-aliceryhl@google.com>
Date:   Thu, 20 Jul 2023 13:30:05 +0000
From:   Alice Ryhl <aliceryhl@...gle.com>
To:     benno.lossin@...ton.me
Cc:     alex.gaynor@...il.com, aliceryhl@...gle.com,
        bjorn3_gh@...tonmail.com, boqun.feng@...il.com, gary@...yguo.net,
        lina@...hilina.net, linux-kernel@...r.kernel.org, nmi@...aspace.dk,
        ojeda@...nel.org, rust-for-linux@...r.kernel.org,
        wedsonaf@...il.com
Subject: Re: [PATCH v2 08/12] rust: init: add support for arbitrary paths in
 init macros

Benno Lossin <benno.lossin@...ton.me> writes:
> Previously only `ident` and generic types were supported in the
> `{try_}{pin_}init!` macros. This patch allows arbitrary path fragments,
> so for example `Foo::Bar` but also very complex paths such as
> `<Foo as Baz>::Bar::<0, i32>`.
> 
> Internally this is accomplished by using `path` fragments. Due to some
> peculiar declarative macro limitations, we have to "forget" certain
> additional parsing information in the token trees. This is achieved by
> using the `paste!` proc macro. It does not actually modify the input,
> since no `[< >]` will be present in the input, so it just strips the
> information held by declarative macros. For example, if a declarative
> macro takes `$t:path` as its input, it cannot sensibly propagate this to
> a macro that takes `$($p:tt)*` as its input, since the `$t` token will
> only be considered one `tt` token for the second macro. If we first pipe
> the tokens through `paste!`, then it parses as expected.
> 
> Suggested-by: Asahi Lina <lina@...hilina.net>
> Signed-off-by: Benno Lossin <benno.lossin@...ton.me>

Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>