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 02:30:08PM +0000, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> 
> > On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
> > >
> > > This kind of thing is why I keep saying build_error() is too fragile to
> > > be used at all.  
> 
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.

The thing about this particular case is that it should have been

	const { Bounded::<u8, 1>::from_expr(1) }

or similar.

You say that this kind of thing would be a compiler bug, but I don't
think the compiler devs folks would agree with us on that at all. I
mean, sure, it's a bug in the sense that it's a missed optimization, but
it's not a correctness bug.

If we used const eval, then suddenly it *would* easily be a compiler
bug, and by the way, it would also work reliably.

> > Adding `unsafe` blocks for things that should be able to be statically
> > known isn't great.
> > 
> > `build_assert!` is just too useful, so it is best to try to understand
> > what can be done, or find an equivalent solution. Gary et al. may have
> > some input here.

I'm not advocating for adding unsafe blocks to skip bounds checks.

And, fine, there are probably a few cases where it works reliably and
has no real replacement. Such as the VTABLE_DEFAULT_ERROR check. But I
do not think bounds checks are a place where it's a good idea.

Alice