On Sat, Sep 20, 2025, at 5:59 PM, Jonas Smedegaard wrote: > Quoting Fabian Grünbichler (2025-09-20 17:31:44) >> On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote: >> > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard <[email protected]> wrote: >> >> Quoting Alexander Kjäll (2025-09-20 16:08:26) >> >> > And regarding running tests in debug, debug have additional checks for >> >> > numeric over-/underflows, something that easily happens when switching >> >> > between 64 and 32 bit architectures. I believe we catch more bugs if we >> >> > don't run the tests with --release. >> >> >> >> Interesting! Can you point to documentation for this? I would like to >> >> understand that better. >> > >> > Here is a section in the book about it: >> > https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow >> > >> >> >> >> It has been my understanding that debug mode builds without optimization >> >> and therefore fails to catch optimization-related errors. >> > >> > This is also true I think. >> > >> > This would be two different classes of errors, don't know how to >> > prioritise between them or if we can have them both. >> >> there's multiple things "enabled" by the default ("dev"/"test") profile, >> compared to the "release" one used for building executables: >> - no optimization (faster builds, but might hide optimization-related >> issues) >> - overflow checks (as noted above) >> - debug assertions (these catch all sort of addition issues) >> >> the latter two are not enabled for release builds because they are quite >> expensive at runtime. >> >> IMHO, in particular for autopkgtests where the same crates are compiled >> possibly tens of times, skipping optimization can mean the difference >> between testing a code path or not testing it at all, so the current >> tradeoff seems sensible to me. > > Do you mean to say that you consider it a sensible tradeoff to *never* > check crate tests with optimizations enabled?
no, I am open to suggestions here. for example, running the dh_auto_test `cargo build/test` and/or the default features autopkgtest with a custom profile (basically dev/test + optimizations) might be a sensible compromise? that should catch most optimization-related issues, while still keeping (test) compilation times down..
