Re: [Pkg-rust-maintainers] Bug#1115714: impossible to install crate zerovec: depends on missing librust-twox-hash-2+xxhash64-dev
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 <dr@jones.dk> 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..
Reply to: