Re: [linux-next:master 4752/13171] error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`

[Daniel Gomez <da.gomez@kernel.org>]

On 04/12/2025 12.47, Andreas Hindborg wrote:
> Hi Oliver,
> 
> "Oliver Sang" <oliver.sang@intel.com> writes:
> 
>> hi, Daniel Gomez,
>>
>> On Tue, Dec 02, 2025 at 10:02:02PM +0100, Daniel Gomez wrote:
>>>
>>>
>>> On 01/12/2025 21.20, kernel test robot wrote:
>>>> Hi Andreas,
>>>>
>>>> FYI, the error/warning still remains.
>>>>
>>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>>> head:   95cb2fd6ce0ad61af54191fe5ef271d7177f9c3a
>>>> commit: 0b08fc292842a13aa496413b48c1efb83573b8c6 [4752/13171] rust: introduce module_param module
>>>> config: arm64-randconfig-001-20251202 (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/config)
>>>> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b3428bb966f1de8aa48375ffee0eba04ede133b7)
>>>> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
>>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251202/202512020454.Tf36WHw5-lkp@intel.com/reproduce)
>>>>
>>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>>> the same patch/commit), kindly add following tags
>>>> | Reported-by: kernel test robot <lkp@intel.com>
>>>> | Closes: https://lore.kernel.org/oe-kbuild-all/202512020454.Tf36WHw5-lkp@intel.com/
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>>>> error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
>>>>    --> rust/kernel/module_param.rs:78:46
>>>>    |
>>>>    78 |         let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
>>>>    |                                              ^^^^^^^^^^^^^^^^ unknown field
>>>>    |
>>>>    = note: available field is: `_address`
>>>>
>>>
>>> I can't replicate this issue either.
>>>
>>> I've added these patches to fix other unrelated build issues, so, I'm not sure
>>> how 0day ended up skipping them? Perhaps it uses head 95cb2fd6c? + bisect?
>>>
>>> a74b6c0e53a6d um: Don't rename vmap to kernel_vmap
>>> f74cf399e02e2 rust: debugfs: Replace the usage of Rust native atomics
>>> 013f912eb5fa7 rust: sync: atomic: Implement Debug for Atomic<Debug>
>>> 14e9a18b07ec4 rust: sync: atomic: Make Atomic*Ops pub(crate)
>>>
>>> My testing branch:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/da.gomez/linux.git/log/?h=20251202-0day-test-0b08fc292842-with-fixes
>>>
>>> FWIW, this is what I've tried:
>>>
>>> rustc --version --verbose
>>> rustc 1.88.0 (6b00bc388 2025-06-23)
>>> binary: rustc
>>> commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
>>> commit-date: 2025-06-23
>>> host: x86_64-unknown-linux-gnu
>>> release: 1.88.0
>>> LLVM version: 20.1.5
>>>
>>> bindgen --version --verbose
>>> bindgen 0.72.1
>>
>> sorry for false positive. we confirmed this is an issue caused by a bug in
>> bindgen - https://github.com/rust-lang/rust-bindgen/issues/3264
>>
>> we used 0.72.0 when saw the issues. now we upgraded to 0.72.1 as you used, now
>> issue disappears.
> 
> Thanks for confirming!

Thanks Oliver!

> 
> While we could see from the config that you were using bindgen 0.72.0,
> it was not clear to us where you get this bindgen from. Obtaining
> bindgen does not seem to be part of the reproducer instructions (or
> maybe I am not looking in the right place?).
> 
> If I understand correctly, this issue manifested only when building
> bindgen 0.72.0 with clang-22-git. Building this was next on our list in
> trying to reproduce, but getting to that conclusion took a while.
> 
> Anyway, I want to ask if you can include directions for obtaining or
> building bindgen in your reproducer instructions?

+ Any reason to use an unreleased clang version for this reports? Since clang-22
is not officially released yet, issues seen with it seem lower priority than
those reproduced with stable, released versions. Does it make sense to act
on these kind of "bleeding edge" reports, or should we wait until they're
confirmed on a stable release? Does 0day test both?

> 
> Best regards,
> Andreas Hindborg
>