Rust on x86_64-unknown-linux-gnu has some preliminary support for sanitizers, per this tracking issue: https://github.com/rust-lang/rust/issues/39699 - asan = AddressSanitizer - lsan = LeakSanitizer - msan = MemorySanitizer - tsan = ThreadSanitizer They need to be turned on with "./configure --enable-sanitizers". This uses LLVM's cmake, which means we'll also need a BuildReq on cmake and llvm-static. And the latter means I'll only want to do this with LLVM 3.9+ where we can force it to still link dynamically to libLLVM.so. (So not on F24.) I thought at first that we'd want to isolate these in a subpackage, because the upstream librustc_?san*.rlib binaries are about 60MB, but once you strip debuginfo they're only 8MB. That's manageable, but still a relatively large addition to the current 31MB rust-std-static. Given the niche use, it may still make sense to package them separately.
Currently, you have to use an unstable -Z option, like -Zsanitizer=asan. This warns that such options are only meant for the nightly compiler, currently accepted for compatibility but will "soon" change. It's been a long time coming, but this was finally blocked on all but nightly: https://github.com/rust-lang/rust/pull/41751 I think we should wait for sanitizers to stabilize before packaging them.
do you have an estimate as to what kind of time frame that would be before they stabilise? Thanks for your work on this mate :)
There's no indication that they're considering stabilization anytime soon. :/ I'll ask on the GH issue though. FWIW, my local test at enabling this did appear to build just fine, though I didn't try using it. But I'd hate to start shipping something that will become inaccessible once 1.19 ships with disabled -Z. In the meantime, can you incorporate rust-nightly into your workflow? It's pretty easy using rustup, and you can still prefer the system compiler like: $ rustup toolchain link system /usr $ rustup default system Then you can use "rustup override" to target nightly for a particular directory, or switch toolchains in ad hoc commands like "cargo +nightly build".
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
I'm deferring this to the upstream issue. If/when the feature stabilizes, we can ship it in the distro too.