[𝘀𝗽𝗿] initial version

Created using spr 1.3.6

Author: qinkunbao

clang/docs/ReleaseNotes.rst

@@ -1045,7 +1045,9 @@ Sanitizers
 ----------
 
 - ``-fsanitize=vptr`` is no longer a part of ``-fsanitize=undefined``.
-- Sanitizer ignorelists now support the syntax ``src:*=sanitize``.
+- Sanitizer ignorelists now support the syntax ``src:*=sanitize``, 
+  ``type:*=sanitize``, ``fun:*=sanitize``, ``global:*=sanitize``,
+  and ``mainfile:*=sanitize``.
 
 Python Binding Changes
 ----------------------

clang/docs/SanitizerSpecialCaseList.rst

@@ -79,7 +79,8 @@ instrumentation for arithmetic operations containing values of type ``int``.
 
 The ``=sanitize`` category is also supported. Any ``=sanitize`` category
 entries enable sanitizer instrumentation, even if it was ignored by entries
-before.
+before. Entries can be ``src``, ``type``, ``global``, ``fun``, and
+``mainfile``.
 
 With this, one may disable instrumentation for some or all types and
 specifically allow instrumentation for one or many types -- including types
@@ -103,7 +104,7 @@ supported sanitizers.
   }
 
 If multiple entries match the source, then the latest entry takes the
-precedence.
+precedence. Here are a few examples.
 
 .. code-block:: bash
 
@@ -119,6 +120,19 @@ precedence.
   src:*/mylib/test.cc
   src:*/mylib/*=sanitize
 
+  $ cat ignorelist3.txt
+  # Type T will not be instrumented.
+  type:*
+  type:T=sanitize
+  type:T
+
+  $ cat ignorelist4.txt
+  # Function `bad_bar`` will be instrumented.
+  # Function `good_bar` will not be instrumented.
+  fun:*
+  fun:*bar
+  fun:bad_bar=sanitize
+
 Format
 ======
 

clang/include/clang/Basic/DiagnosticGroups.td

@@ -813,19 +813,19 @@ changes to one object won't affect the others, the object's initializer will run
 once per copy, etc.
 
 Specifically, this warning fires when it detects an object which:
-  1. Is defined as ``inline`` in a header file (so it might get compiled into multiple libaries), and
-  2. Has external linkage (otherwise it's supposed to be duplicated), and
-  3. Has hidden visibility.
+1. Is defined as ``inline`` in a header file (so it might get compiled into multiple libaries), and
+2. Has external linkage (otherwise it's supposed to be duplicated), and
+3. Has hidden visibility.
 
 As well as one of the following:
-  1. The object is mutable, or
-  2. The object's initializer definitely has side effects.
+1. The object is mutable, or
+2. The object's initializer definitely has side effects.
 
 The warning can be resolved by removing one of the conditions above. In rough
 order of preference, this may be done by:
-  1. Marking the object ``const`` (if possible)
-  2. Moving the object's definition to a source file
-  3. Giving the object non-hidden visibility, e.g. using ``__attribute((visibility("default")))``.
+1. Marking the object ``const`` (if possible)
+2. Moving the object's definition to a source file
+3. Giving the object non-hidden visibility, e.g. using ``__attribute((visibility("default")))``.
 
 Note that for (2), all levels of a pointer variable must be constant;
 ``const int*`` will trigger the warning because the pointer itself is mutable.