Details
Diff Detail
Event Timeline
Nice! I like the idea, but we need to figure out a bunch of details (see the comments inline).
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
303 | ConfigFile.str() should also work. | |
clang-tidy/tool/ClangTidyMain.cpp | ||
131 | I would expect something different from an option named '-explain-checks', e.g. some kind of a short documentation on each check or the like. Something like explain-config or describe-config would be closer to what the option does, I think. | |
132 | How about for each enabled check explains, where it is enabled, i.e. in clang-tidy binary, command line or a specific configuration file? | |
265 | s/ClangTidy/clang-tidy/ | |
277 | s/argument 'checks'/option '-checks'/ | |
291 | s/argument 'config'/option '-config'/ | |
321 | I'm not sure I understand how this should work in case a check is:
clang-tidy should say 'command line' in this case, but i'm not sure what your implementation will do, since it doesn't seem to keep the order of the configurations. | |
323 | nit: Filter You could also write if (GlobList(CheckSource.first).contains(Check)) { | |
325 | s/comes from/is enabled in the/ |
clang-tidy/tool/ClangTidyMain.cpp | ||
---|---|---|
321 | I updated the patch and made sure the behavior keep the order of configuration. But if the case like:
Only command-line option -checks will be diagnosed, since the processor order of configuration is binary -> config file -> command-line option -checks. |
clang-tidy/tool/ClangTidyMain.cpp | ||
---|---|---|
321 | As discussed offline, the order of iteration matters here. And it looks like we should look at the complete Checks options without splitting them to components (in order to handle negative patterns). |
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
304 | Can we use .emplace_back here? | |
clang-tidy/ClangTidyOptions.h | ||
91 | If it's from low to high, I'd use < instead of > to avoid confusion ;) | |
99 |
| |
104 | Can we store a single vector of string pairs instead of three different vectors? The second item of the pair already says enough about the source. And this being an array doesn't seem to be useful. | |
clang-tidy/tool/ClangTidyMain.cpp | ||
279 | Please pull this string literal to a constant: it's used more than once in the code. Maybe also pull the "clang-tidy binary" string too, for consistency. |
clang-tidy/tool/ClangTidyMain.cpp | ||
---|---|---|
279 | Err, the strings are actually different, but I'd still make all three of them constants. |
I've just realized that the approach is artificially limited to just keeping track of the origin of the Checks option, while it could be easily extended to track the origin of all configuration items. What if instead of std::vector<StringPair> CheckSources; we introduce std::vector<std::pair<std::string, ClangTidyOptions>> Sources;? Then we could be able to find where a certain check option or an extra argument was introduced, for example. WDYT?
clang-tidy/tool/ClangTidyMain.cpp | ||
---|---|---|
188 | One problem with this way of defining string constants is that they are not constants. CheckSourceTypeDefaultBinary = "oops"; will work just fine. Instead, I prefer to use constexpr char XXX[] = "..."; construct. |
Update the patch according to our offline discussion. One different thing is that we can't assume that Other in merge(CTO& Other) has empty HigherPriorityOptions because some usages break this assumption.
clang-tidy/ClangTidyOptions.h | ||
---|---|---|
99 | As per offline discussion, there might be a more elegant and robust solution to this. For example, extending the ClangTidyOptionsProvider interface with a virtual getRawOptions method (ideas for a better name are welcome) returning an ordered list of ClangTidyOption objects accompanied by textual descriptions of their origin (defaults/configuration file name/command line option name). The virtual ClangTidyOptions getOptions(llvm::StringRef FileName); method can then be made non-virtual and serve as an interface for option consumers only (it would just merge all options returned by the former method). |
Looks better now, thanks!
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
163 | I'm not sure this will compile on VS2013. | |
179 | Maybe emplace_back? | |
clang-tidy/ClangTidyOptions.h | ||
129 | Clang-format, please. | |
245 | nit: Name should start with a lower-case letter. | |
clang-tidy/tool/ClangTidyMain.cpp | ||
326 | No need for parentheses around It->first.Checks. |
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
163 | Yeah, you are right. VS2013 doesn't work with vector brace-initialization. |
Sorry for the long delay. This is getting closer. A few more comments though.
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
224 | s/ = \s*OptionsSource// | |
235 | This seems to be changing the caching logic. Consider this directory structure: a/ .clang-tidy b/ c/ And consequtive getRawOptions calls with:
What would happen previously:
Now step 2 doesn't copy the cache entry to "a/b" and "a/b/c". Is there any specific reason to change this? This is benign given that the lookups happen in memory, but then the code needs to be consistent and avoid replicating cache entries to intermediate directories in all cases. | |
clang-tidy/ClangTidyOptions.h | ||
102 | As we figured out with another patch, constexpr is not supported by VS2013. Sorry for pushing you in a wrong direction. | |
115 | s/from low to top/in order of increasing priority/ | |
117 | This item should make it clear how a config file relates to the '-config' option in terms of priority. The easiest way to make the order clear is probably to split the item in two (and update the "3 types of the sources" above). | |
127 | Let's move the implementation to the .cpp file. It's only used by a small fraction of translation units including this header, and it doesn't seem to be performance-critical to make this method inline. | |
145 | clang-format? A few more instances below. | |
161 | clang-format? | |
clang-tidy/tool/ClangTidyMain.cpp | ||
320 | "a more elegant way" seems to suggest that currently this already happens, but in a not elegant fashion. As far as I understand, we're not doing this at all ;) |
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
235 | Oh, I add a break statement here accidently. Remove it, and keep the caching logic here now. | |
clang-tidy/ClangTidyOptions.h | ||
117 | Explaining the priority of config option and config file is't reasonable here since clang-tidy only takes one of them. If the config option is specified, clang-tidy just ignores the config file. |
Looks good with one nit.
Thank you for implementing this!
clang-tidy/tool/ClangTidyMain.cpp | ||
---|---|---|
320 | Sorry for being not clear. We still need to find a way to display the source of other components of the configuration. So the FIXME was fine, just the wording was confusing. Please add the FIXME back, but just remove the "more elegant" part. |
One more nit.
clang-tidy/ClangTidyOptions.h | ||
---|---|---|
239–240 | clang-format? Consider making git clang-format handle it for you ;) |
clang-tidy/ClangTidyOptions.h | ||
---|---|---|
239–240 | Done. Format the whole patch now. |
If it's from low to high, I'd use < instead of > to avoid confusion ;)