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

[Philip Li <philip.li@intel.com>]

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?

> 
> Cheers,
> Miguel
>