[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+tqQ4+HA=XsPuuU+-orr+sMOzHWtjPxaXZFF6FPUY+Q+jzQdw@mail.gmail.com>
Date: Sun, 11 Jan 2026 10:21:57 +0900
From: Jesung Yang <y.j3ms.n@...il.com>
To: Tamir Duberstein <tamird@...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 v2 1/2] scripts: generate_rust_analyzer: add versioning infrastructure
On Sat, Jan 10, 2026 at 8:08 AM Tamir Duberstein <tamird@...il.com> wrote:
>
> I think we can get all the information we need about the compiler
> without shelling out to RA here. In KConfig we already have options
> like
>
> config RUSTC_HAS_COERCE_POINTEE
> def_bool RUSTC_VERSION >= 108400
>
> and those configs all flow through scripts/generate_rust_analyzer.py.
> Could we add one to indicate the new version of RA, and then drive the
> logic from it?
This could be an option, but I'm hesitant to use Kconfig soley for
tooling enhancements which don't affect the kernel binary. I'd like to
get a bit more input on whether this approach aligns with how we want
to use Kconfig.
Best regards,
Jesung
Powered by blists - more mailing lists