On Fri, Feb 21, 2025 at 04:58:59AM +0100, Miguel Ojeda wrote:

Hi Alistair,

On Fri, Feb 21, 2025 at 2:20 AM Alistair Popple [off-list ref] wrote:

quoted

Is this a known issue or limitation? Or is this a bug/rough edge that still
needs fixing? Or alternatively am I just doing something wrong? Would appreciate
any insights as figuring out what I'd done wrong here was a bit of a rough
introduction!

Yeah, it is a result of our `build_assert!` machinery:

    https://rust.docs.kernel.org/kernel/macro.build_assert.html

which works by producing a build (link) error rather than the usual
compiler error and thus the bad error message.

`build_assert!` is really the biggest hammer we have to assert
something is true at build time, since it may rely on the optimizer.
For instance, if `static_assert!` is usable in that context, it should
be instead of `build_assert!`.

Ideally we would have a way to get the message propagated somehow,
because it is indeed confusing.

Are there any proposals or ideas for how we could do that?

I hope that helps.

Kind of, but given the current state of build_assert's and the impossiblity of
debugging them should we avoid adding them until they can be fixed?

Unless the code absolutely cannot compile without them I think it would be
better to turn them into runtime errors that can at least hint at what might
have gone wrong. For example I think a run-time check would have been much more
appropriate and easy to debug here, rather than having to bisect my changes.

I was hoping I could suggest CONFIG_RUST_BUILD_ASSERT_ALLOW be made default yes,
but testing with that also didn't yeild great results - it creates a backtrace
but that doesn't seem to point anywhere terribly close to where the bad access
was, I'm guessing maybe due to inlining and other optimisations - or is
decode_stacktrace.sh not the right tool for this job?

Thanks.

 - Alistair

Cheers,
Miguel