linux-kernel - Re: [PATCH] scripts: generate_rust_analyzer.py: better pin-init macro resolvea

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: <CAGAB664nN_drDtG3HA=evO4m1o8pyYohQTXxC4D5X2x6VL72ig@mail.gmail.com>
Date: Fri, 23 Jan 2026 22:14:02 +0900
From: 하승종 <engineer.jjhama@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scripts: generate_rust_analyzer.py: better pin-init macro resolvea

2026년 1월 23일 (금) PM 7:26, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>님이 작성:
>
> On Fri, Jan 23, 2026 at 11:02 AM SeungJong Ha via B4 Relay
> <devnull+engineer.jjhama.gmail.com@...nel.org> wrote:
> >
> > From: SeungJong Ha <engineer.jjhama@...il.com>
> >
> > Signed-off-by: SeungJong Ha <engineer.jjhama@...il.com>
>
> The commit message appears to be empty -- I think you may have wanted
> to use the text below the `---`, since I see another title there
> (although it isn't exactly worded like the usual commit message
> either, i.e. with "Hello" etc., so I am not sure what happened in this
> one).
>
> Also, typo in the (patch) title.

I got it, maybe I got something wrong on my b4,
Let me check and get back to you!

>
> > @@ -123,10 +123,18 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
> >      append_crate(
> >          "pin_init_internal",
> >          srctree / "rust" / "pin-init" / "internal" / "src" / "lib.rs",
> > -        [],
> > +        ["std", "proc_macro"],
> >          cfg=["kernel"],
> >          is_proc_macro=True,
> >      )
>
> Is this commit 74e15ac34b09 ("scripts: generate_rust_analyzer: Add
> pin_init_internal deps")?
>
> I think you based this on top of `rust-next` so you did not see the
> fixes currently queued in `rust-fixes` (soon to arrive in mainline).
>

Oh, I was wandering the project on `rust-next`.
I will make v2 rebased on `rust-fixes`

> > +    # pin_init_internal uses #[path = "../../../macros/quote.rs"] to include quote.rs
>
> For comments etc., we use the usual style used in other Rust files, e.g.
>

Got it!

>     # `pin_init_internal` uses `#[path = "../../../macros/quote.rs"]`
> to include `quote.rs`.
>
> > +            str(srctree / "rust" / "pin-init" / "internal" / "src"),
> > +            str(srctree / "rust" / "macros"),
>
> There is this rule in rust-analyzer about `source`:
>
>     /// If two crates share an `.rs` file in common,
>     /// they *must* have the same `source`.
>     /// rust-analyzer assumes that files from one
>     /// source can't refer to files in another source.
>
> I am not sure how that is supposed to work or why rust-analyzer
> requires it, i.e. does it mean `macros` must have also the `pin-init`
> path too? Or just that, for each file, the path that included it (not
> the entire `source`) must match?

I had some brief experiments(after rebase to rust-fixes).
It seems to be related with lsp's "go to reference" feature.
Without this patch,
1. The analyzer fails to resolve the mod `quote` on
`rust/pin-init/internal/src/lib.rs`.
2. The analyzer also fails to find references outside of the
`rust/macros` directory.

And I couldn't find `pin-init` usage on the `macro` crate.

So I guess the latter one has more sounds.

>
> If the former, we may be also "abusing" it in the other place we use
> `source` for the generated files. If the latter, then it is fine
> there, but here we would need `macros` to also have the path, I guess.
>
> Or perhaps that "rule" in the docs isn't as strict as it sounds?

    /// By default, rust-analyzer assumes that only
    /// files under `root_module.parent` can belong
    /// to a crate. `include_dirs` are included
    /// recursively, unless a subdirectory is in
    /// `exclude_dirs`.
    ///
    /// Different crates can share the same `source`.
    ///
    /// If two crates share an `.rs` file in common,
    /// they *must* have the same `source`.
    /// rust-analyzer assumes that files from one
    /// source can't refer to files in another source.

I think the analyzer already includes the path while the parent of `macro` lib
already contains `quote`!

>
> Thanks!
>
> Cheers,
> Miguel