pass kernel configurations to the macros crate to prevent rust-analyzer
from marking conditionally included macros as 'never included'.
Add the generated configurations to the macros cfg list
so rust-analyzer correctly hints inclusion and exclusion.

Signed-off-by: Malte Wechter <maltewechter@gmail.com>
---
 scripts/generate_rust_analyzer.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index d5f9a0ca742c..69990a96522e 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -238,6 +238,7 @@ def generate_crates(
         "macros",
         srctree / "rust" / "macros" / "lib.rs",
         [std, proc_macro, proc_macro2, quote, syn],
+        cfg=generated_cfg,
     )
 
     build_error = append_crate(

---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260506-rust-analyzer-macro-22f387f8eff4

Best regards,
-- 
Malte Wechter <maltewechter@gmail.com>

On Fri, May 8, 2026 at 3:04 AM Malte Wechter <maltewechter@gmail.com> wrote:
>
> pass kernel configurations to the macros crate to prevent rust-analyzer
> from marking conditionally included macros as 'never included'.
> Add the generated configurations to the macros cfg list
> so rust-analyzer correctly hints inclusion and exclusion.
>
> Signed-off-by: Malte Wechter <maltewechter@gmail.com>

Hi Malte, thanks for your patch. I haven't seen this issue. Could you
please help me reproduce what you're seeing?

Directionally I think this patch is incorrect because the macros crate
is a host-side crate and generated_cfg is for target-side cfgs.

Tamir

Hi Tamir,

"Tamir Duberstein" <tamird@kernel.org> writes:

> On Fri, May 8, 2026 at 3:04 AM Malte Wechter <maltewechter@gmail.com> wrote:
>>
>> pass kernel configurations to the macros crate to prevent rust-analyzer
>> from marking conditionally included macros as 'never included'.
>> Add the generated configurations to the macros cfg list
>> so rust-analyzer correctly hints inclusion and exclusion.
>>
>> Signed-off-by: Malte Wechter <maltewechter@gmail.com>
>
> Hi Malte, thanks for your patch. I haven't seen this issue. Could you
> please help me reproduce what you're seeing?

We are moving some of the configfs macro logic to procedural
implementations, now that we have syn. We are going to gate the macro on
CONFIG_CONFIGFS_FS. Malte noticed that rust-analyzer does not understand
the gating in the macros crate. rust-analyzer does not know that
CONFIG_CONFIGFS_FS is set, so rust-analyzer does not function at all for
our module:

--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -15,6 +15,8 @@
 #![cfg_attr(not(CONFIG_RUSTC_HAS_SPAN_FILE), feature(proc_macro_span))]

 mod concat_idents;
+#[cfg(CONFIG_CONFIGFS_FS)]
+mod configfs_attrs;
 mod export;

> Directionally I think this patch is incorrect because the macros crate
> is a host-side crate and generated_cfg is for target-side cfgs.

We might want to differentiate macro implementations based on kernel
configuration, or as in our case, skip compilation of certain macros
when they are not used in the kernel build.


Best regards,
Andreas Hindborg

Andreas Hindborg <a.hindborg@kernel.org> writes:

<cut>

>> Directionally I think this patch is incorrect because the macros crate
>> is a host-side crate and generated_cfg is for target-side cfgs.
>
> We might want to differentiate macro implementations based on kernel
> configuration, or as in our case, skip compilation of certain macros
> when they are not used in the kernel build.

Also, the `macros` crate is actually built with these configuration
attributes applied. It is only logical that the `rust-analyzer`
configuration reflect how we build the crate.


Best regards,
Andreas Hindborg

On Mon, May 11, 2026 at 1:00 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> Andreas Hindborg <a.hindborg@kernel.org> writes:
>
> <cut>
>
> >> Directionally I think this patch is incorrect because the macros crate
> >> is a host-side crate and generated_cfg is for target-side cfgs.
> >
> > We might want to differentiate macro implementations based on kernel
> > configuration, or as in our case, skip compilation of certain macros
> > when they are not used in the kernel build.
>
> Also, the `macros` crate is actually built with these configuration
> attributes applied. It is only logical that the `rust-analyzer`
> configuration reflect how we build the crate.

Hi Andreas,

These justifications should be in the commit message. I agree that the
`macros` crate is receiving those cfgs, that was added in 36174d16
("rust: kunit: support KUnit-mapped `assert!` macros in `#[test]`s") -
this should also be mentioned in the commit message please.