The config providers that look for configuration files currently take a pointer to a FileSystem in the constructor.
For some reason this isn't actually used when trying to read those configuration files, Essentially it just follows the behaviour of the real filesystem.
Using clang-tidy standalone this doesn't cause any issue.
But if its used as a library and the user wishes to use say an InMemoryFileSystem it will try to read the files from the disc instead.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
LGTM aside from a nit with the test.
clang-tools-extra/unittests/clang-tidy/OptionsProviderTest.cpp | ||
---|---|---|
68 | Can you add the newline to the end of the file? |
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
366 | This breaks bootstrap builds against the gcc 5.3 libstdc++: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8864218000842553296/+/steps/package_clang/0/stdout?format=raw /b/s/w/ir/cache/builder/src/third_party/llvm/clang-tools-extra/clang-tidy/ClangTidyOptions.cpp:366:12: error: no matching constructor for initialization of 'clang::tidy::ClangTidyOptionsProvider::OptionsSource' (aka 'pair<clang::tidy::ClangTidyOptions, basic_string<char>>') return OptionsSource(*ParsedOptions, ConfigFile.str()); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Can we undo the change on this line? PTAL! |
This breaks bootstrap builds against the gcc 5.3 libstdc++: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8864218000842553296/+/steps/package_clang/0/stdout?format=raw
Can we undo the change on this line?
PTAL!