[clang] [rtsan][NFC] Documentation of suppression flag (PR #112727)

via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 17 09:44:27 PDT 2024


================
@@ -194,12 +198,43 @@ Some issues with flags can be debugged using the ``verbosity=$NUM`` flag:
    misspelled_flag
    ...
 
-Disabling
----------
+Disabling and suppressing
+-------------------------
 
-In some circumstances, you may want to suppress error reporting in a specific scope.
+There are multiple ways to suppress error reporting when using RealtimeSanitizer.
 
-In C++, this is achieved via  ``__rtsan::ScopedDisabler``. Within the scope where the ``ScopedDisabler`` object is instantiated, all sanitizer error reports are suppressed. This suppression applies to the current scope as well as all invoked functions, including any functions called transitively.
+In general, ``ScopedDisabler`` should be preferred, as it is the most performant.
+
+.. list-table:: Suppression methods
+   :widths: 30 15 15 10 70
+   :header-rows: 1
+
+   * - Suppression method
+     - Specified at?
+     - Scope
+     - Run-time cost
+     - Description
+   * - ``ScopedDisabler``
+     - Compile-time
+     - Stack
+     - Very low
----------------
davidtrevelyan wrote:

Totally understood, and well phrased question - is what is happening under the hood helpful? In general it depends on the context, of course. For something like choosing between `std::map` vs `std::unordered_map` for performance reasons, it's critical to know what's happening under the hood. For choosing what json library to use in an application that isn't performance sensitive, it doesn't matter - I just care about the API being easy to use. So where does rtsan fall on that spectrum? I think probably somewhere in the middle, but I suspect leaning more towards the "I don't care" side. So maybe we just leave this as it is, and add more detail if people request it? I don't feel strongly either way on this one, just wanted to raise the question in case it rung some alarm bells. 

https://github.com/llvm/llvm-project/pull/112727


More information about the cfe-commits mailing list