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@xxxxxxxxxx> 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
