![]() The commands database is also stored in the root directory in a file named compile_commands.json. Precisely, I use run-clang-tidy.py python script, as follows: run-clang-tidy.py -header-filter='.*' -checks='-*,readability-braces-around-statements' -fix In comparison to the proposed header-filter + exclude-header-filter glob list makes it possible to naturally express restrictions similar to "everything under a/ (except for everything under a/b/ (except for everything under a/b/c/))" - a/,-a/b/,a/b/c/.I ran clang-tidy (Clang-Extra-Tools 6.0.0) in the root directory of the source code of an application ( MPlayer-1.3.0). It should be a convenient tool to represent a set of files / directories. ), and allows to easily express exclusion of subsets. On the flipside, glob list has a cleaner syntax (no need to quote characters common in paths - like. If needed, the support can be expanded with ?, character classes, character ranges and/or other features of POSIX globs ( ). Repeating my question from an earlier comment: would a header glob list (similar to how the format of the -checks= flag) be enough for the use cases folks have? On the one hand glob list doesn't support all the features of regular expressions, but are they all useful for matching paths? Glob list in clang-tidy currently supports set union (similar to regex |) and - * (regex. So the owner of a subdirectory tree should see all warnings for their tree, but consumers of headers should not be bothered. What we really want is to be able to segregate warnings per component (a subdirectory tree) and don't bother people who import headers from other subdirectory trees with local warnings. In the worst case, we're really comparing 1 hour to a few minutes.Įven the first approach is not so interesting, as we would like warnings for another subdirectory tree to be visible in this subdirectory. We implemented this patch in our local installation, and it dramatically reduces the time it takes to run clang-tidy on a "component", where we can focus on the source and header files in a subdirectory tree, and exclude headers from other subdirectories. It's not so much the warnings that are an issue, but generating the notes is taking a lot of time. This approach does not work for us, as our external headers generate a lot of warnings. I'm not sure though whether this suits your needs or is an overkill. The second way to handle this use case is possible on a different level: one can run clang-tidy over the whole project with -header-filter=.* and then filter the results and use a specialized tool to display them, e.g. This seems like a more logical and useful behavior, however, when implementing this we'll have to make sure configuration retrieval doesn't become a bottleneck (FileOptionsProvider already implements some sort of caching, but we'd have to carefully benchmark it on large translation units with tons of diagnostics). * by default), in the case above it would output check1 and check2 from a/a.cpp and a/a.h, check2 from b/b.h (since we don't even run check3 on the code, and check1 gets filtered out), and no diagnostics from third-party/c.h, since we filter out check1 and check2 according to the local configuration. If we change clang-tidy to apply the most relevant local configuration to the generated diagnostics (and get rid of -header-filter altogether, or set it to. header-filter=.* will result in check1 and check2 diagnostics from all the files. Currently, when run on a.cpp without -header-filter, clang-tidy would only output check1 and check2 from a.cpp. Let's assume that each of a/a.h, b/b.h, third-party/c.h and a/a.cpp contain code that triggers check1, check2 and check3. A/a.cpp: #include a/a.h, #include b/b.h, #include third-party/c.h
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |