================
@@ -645,31 +663,32 @@ Here's an example:
// CHECK-FIXES-USING-B-NOT: using a::B;$
// CHECK-FIXES-NOT: using a::C;$
-There are many dark corners in the C++ language, and it may be difficult to
make
-your check work perfectly in all cases, especially if it issues fix-it hints.
The
-most frequent pitfalls are macros and templates:
-
-1. Code written in a macro body/template definition may have a different
meaning
- depending on the macro expansion/template instantiation.
-2. Multiple macro expansions/template instantiations may result in the same
code
- being inspected by the check multiple times (possibly, with different
- meanings, see 1), and the same warning (or a slightly different one) may be
- issued by the check multiple times; :program:`clang-tidy` will deduplicate
- _identical_ warnings, but if the warnings are slightly different, all of
them
- will be shown to the user (and used for applying fixes, if any).
-3. Making replacements to a macro body/template definition may be fine for some
- macro expansions/template instantiations, but easily break some other
+There are many dark corners in the C++ language, and it may be difficult to
+make your check work perfectly in all cases, especially if it issues fix-it
+hints. The most frequent pitfalls are macros and templates:
+
+1. Code written in a macro body/template definition may have a different
+ meaning depending on the macro expansion/template instantiation.
+2. Multiple macro expansions/template instantiations may result in the
+ same code being inspected by the check multiple times (possibly, with
+ different meanings, see 1), and the same warning (or a slightly different
+ one) may be issued by the check multiple times; :program:`clang-tidy` will
+ deduplicate _identical_ warnings, but if the warnings are slightly
+ different, all of them will be shown to the user (and used for applying
+ fixes, if any).
+3. Making replacements to a macro body/template definition may be fine for
+ some macro expansions/template instantiations, but easily break some other
expansions/instantiations.
If you need multiple files to exercise all the aspects of your check, it is
-recommended you place them in a subdirectory named for the check under the
``Inputs``
-directory for the module containing your check. This keeps the test directory
from
-getting cluttered.
+recommended you place them in a subdirectory named for the check under the
+``Inputs`` directory for the module containing your check. This keeps the
+test directory from getting cluttered.
-If you need to validate how your check interacts with system header files, a
set
-of simulated system header files is located in the ``checkers/Inputs/Headers``
-directory. The path to this directory is available in a lit test with the
variable
-``%clang_tidy_headers``.
+If you need to validate how your check interacts with system header files, a
+set of simulated system header files is located in the
+``checkers/Inputs/Headers`` directory. The path to this directory is
----------------
EugeneZelenko wrote:
```suggestion
``checkers/Inputs/Headers`` directory. The path to this directory is
```
https://github.com/llvm/llvm-project/pull/168722
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
