Currently we have:

• A rustc flag, -Z sanitizer, to sanitize rlibs (it adds an extra LLVM pass/attribute) and executables (it links to the sanitizer runtime). Added in LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support #38699.

• An attribute #[no_sanitize] to disable sanitization on specific functions. Also lints if those functions are marked as requesting inlining. Added in Selectively disable sanitizer instrumentation #68164.

  • #[no_sanitize] suppresses #[inline] hints. A lint is issued if combined with #[inline(always)].

• A few violations (false positives?) in the test runner

  • ThreadSanitizer detects a data race in the test runner (rustc --test) ThreadSanitizer detects a data race in the test runner (rustc --test) #39608
  • MemorySanitizer detects an use of unitialized value in the test runner (rustc --test) MemorySanitizer detects an use of unitialized value in the test runner (rustc --test) #39610

• Known issues

  • Incremental compilation breaks sanitizers Incremental compilation breaks sanitizers #39611

• Unresolved questions:

  • Should we call the attribute #[no_sanitize] or perhaps something like #[sanitize(never)] or some other variation? In particular, might we at some point want "positive options" like #[sanitize(miri(aggressive))]? There is much back and forth in Selectively disable sanitizer instrumentation #68164.
  • What should the user experience be to enable sanitizers, particularly when using cargo? Should cargo have first-class support? Is that blocked on build-std stabilizing?