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 04:53:26PM +0100, Miguel Ojeda wrote:
> On Fri, Nov 21, 2025 at 3:44 PM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > 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.
> 
> > 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.
> 
> There may be no guarantees, but it is a similar situation as for C
> compilers in the kernel.

I don't think it is like that at all. We rely on non-guaranteed behavior
for data races because we have no choice and we had extensive discussion
about it with the compiler folks who are comfortable with us using that
particular exception.

> Compilers can of course change behavior and have bugs and so on, and
> thus avoiding to rely on it as much as possible is a good idea, but I
> think it is a good idea to get build asserts reliably working as much
> as possible for certain use cases. In particular, I don't see why
> simple (local-enough) bounds checks cannot be one of those (it may not
> be today, but it could).
> 
> Of course, the best would be to get the language to a point where it
> supports this sort of thing natively. But that is a longer road.
> 
> And, in some situations, there may be no good alternative (i.e. const
> eval / generics / macros may be too painful to apply), and thus people
> may end up adding `unsafe` instead, which isn't great.

The difference is that someone adding unsafe to avoid a bounds check
screams to the reviewers that something sketchy is going on. In
comparison, drivers calling `Bounded::from_expr(_)` with a non-trivial
expression looks like entirely normal code even though it might be
relying on the precise and definitely subject-to-change details of when
LLVM is choosing to inline various functions.

If const eval / generics / macros are too painful, then perform a
runtime bounds check just like everyone who uses Rust outside of the
kernel is doing.

> In addition, I think upstream probably wants to know about this sort
> of this, i.e. sometimes the changes may be unintended (i.e. if we see
> it changing in a new nightly) and they probably like to hear about
> "obvious" optimizations not being applied, since they are potential
> easy wins for them (or, rather, avoiding regressions), as Gary
> mentions. That is also part of the value of building the kernel in
> compiler CIs etc.

I do not at all think it's obvious that upstream would be happy about
this, considering it comes with the serious trade-off of us relying on
these optimizations happening.

Alice