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

Andreas Hindborg
2025-12-05T10:43:32Z

"Philip Li" <philip.li@intel.com> writes:

> On Thu, Dec 04, 2025 at 01:24:03PM +0100, Miguel Ojeda wrote:
>> On Thu, Dec 4, 2025 at 12:59 PM Daniel Gomez <da.gomez@kernel.org> wrote:
>> >
>> > + 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?
>>
>> Some people in the kernel regularly test with unreleased compilers
>> (all GCC, Clang and Rust) in order to fix issues before those
>> compilers get actually released, e.g. ClangBuiltLinux for LLVM, I do
>> it for `rustc`, several people for GCC, etc.
>>
>> So I guess the idea is similar for kernel test robot? There is value
>> on doing that, and whether one should act depends -- if it is close to
>> the release of the compiler, then it makes sense to try to figure out
>> what is breaking so that the compiler has a chance to fix it.
>> Otherwise, if nobody tries, we would get quite broken compilers (for
>> the kernel use case at least).
>
> thanks, the bot tests multiple versions of compiler for both gcc and clang.
> For clang, low confidence ones will only be sent to llvm mailing list for
> check firstly, and for other issues, we will cc llvm mailing list who also
> monitor this closely and help check in case there's issue in latest compiler.
>
>>
>> It is also why I think having at least a basic kernel build on the
>> upstream CIs of the compilers is a good idea (it already showed value
>> in upstream Rust and perhaps we should talk about it again in LPC for
>> Clang).
>>
>> But, yeah, the reports can be confusing and reacting to them properly
>> does take time and effort (e.g. I need sometimes to bisect the
>> compiler etc.).
>>
>> Does LKP try the bleeding edge versions only if a stable compiler
>> built successfully? That could perhaps help.
>
> For bleeding edge, the bot regularly builds and use latest code now.
>
>>
>> Andreas also suggested yesterday in our meeting to have such bleeding
>> edge reports perhaps more clearly marked or similar.
>
> Probably we can mark rust issue as low confidence when it occurs on non
> released compiler, so it will not be directly sent to developer before it
> is further checked?

Would it be possible to still send the report, but to inject a line to
the report stating it is marked as low confidence due to X and Y
(unreleased compiler etc.)?

I think it is still valuable to get the reports, but it would be nice to
know we don't need to scramble all hands on deck immediately.

I guess one could also just read the report more carefully to learn
that an unreleased compiler was used. But seeing this at a glance would
be great.

Best regards,
Andreas Hindborg