Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alice Ryhl <aliceryhl@google.com>]

On Fri, Nov 21, 2025 at 03:13:16PM +0900, Alexandre Courbot wrote:
> On Fri Nov 21, 2025 at 1:41 AM JST, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
> > commit: 01e345e82ec3a5a7edeb9fa0dcb7fd4b0e5c534e [9676/10599] rust: num: add Bounded integer wrapping type
> > config: loongarch-randconfig-6002-20251120 (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/config)
> > compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
> > rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-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/202511210055.RUsFNku1-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>):
> >
> >>> ld.lld: error: undefined symbol: rust_build_error
> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u8, 1>>::from_expr) in archive vmlinux.a
> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u32, 4>>::from_expr) in archive vmlinux.a
> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u16, 8>>::from_expr) in archive vmlinux.a
> 
> Mmm, I don't like this. The expressions that are failing are extremely
> simple, for instance:
> 
>     Bounded::<u8, 1>::from_expr(1)
> 
> So if the compiler is unable to assess that this won't fail, this might
> be a deal-breaker for `from_expr` and we might need to remove it. :(
> 
> This would also mean a lot more runtime checks when working with
> bitfields and registers. Or can we assume that this is a compiler
> problem on this particular architecture?

Yeah, it sounds like from_expr() isn't going to work.

Alice