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 Fri, Dec 05, 2025 at 11:43:21AM +0100, Andreas Hindborg wrote:
> "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.)?

Got it, i can add a new line or update the reproduce line from

	reproduce (this is a W=1 build):

To

	reproduce (this is a W=1 build on unreleased compiler):

I can wait for a while to see any other comments regarding this. And
of course, this can be refined at any time in the future to make the
report clear.

> 
> 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.

Got it, sorry for this time's unclear info.

> 
> 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
> 
>