We're using different clang-tidy frontends (command-line, batch analysis jobs, code review integration), some of which are limited in the choice of configuration format. In order to avoid duplication of configuration information, we need to support the same configuration format in the command-line tool. This patch adds an extension point to make this possible without rewriting FileOptionsProvider.
Details
Diff Detail
Event Timeline
clang-tidy/ClangTidyOptions.h | ||
---|---|---|
129 | I think the naming here is quite confusing:
I suggest swappin #2 and #3 or renaming ConfigHandler to ConfigFileHandler. |
Either the patch description or the FileOptionsProvider need a lot more documentation describing the intended usage. This should roughly outline why you might want to parse different configuration files/formats and what you need to implement to do so.
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
184 | Not a strong opinion, but using the concrete type here might help understanding this later. | |
200–209 | I'd move this part of the function into getOptions(): | |
clang-tidy/ClangTidyOptions.h | ||
127 | I think a ConfigFileHandler should be a proper class and have (at least) three methods:
Not all of them have to be implemented for all handlers, but that seems like a set of useful functionality. Also, at least the pair's string needs to be documented. | |
177 | This should document in which order config handlers are tried. |
Added/updated comments, moved the loop over config handlers inside
TryReadConfigFile.
clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
184 | Done. | |
200–209 | These are valid points. I've addressed these using the opposite approach: made TryReadConfigFile try all configuration file handlers. | |
clang-tidy/ClangTidyOptions.h | ||
127 | I don't feel that these methods will be immediately useful. We can add them (or alternatives) once we're have the need to surface relevant functionality (e.g. listing supported configuration formats and choosing the format for -dump-config) in the command-line interface. For now, I suggest leaving it as a pair. I'm adding a comment describing its content and usage. | |
177 | Done. |
I think a ConfigFileHandler should be a proper class and have (at least) three methods:
Not all of them have to be implemented for all handlers, but that seems like a set of useful functionality.
Also, at least the pair's string needs to be documented.