================
@@ -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
----------------
EugeneZelenko wrote:

```suggestion
``Inputs`` directory for the module containing your check. This keeps the
```

https://github.com/llvm/llvm-project/pull/168722
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to