Re: [PATCH v7 07/16] rust: add `io::{Io, IoRaw}` base types

Alistair Popple
2025-02-25T05:50:12Z

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 <apopple@nvidia.com> wrote:
> >
> > 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