Open
Description
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
- ThreadSanitizer detects a data race in the test runner (
-
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?
- Should we call the attribute
Metadata
Metadata
Assignees
Labels
Area: Command-line interface (CLI) to the compilerArea: Sanitizers for correctness and code qualityBlocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCStatus: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Relevant to the dev-tools subteam, which will review and decide on the PR/issue.