================
@@ -266,7 +266,7 @@ ClangTidyOptions
ClangTidyContext::getOptionsForFile(StringRef File) const {
// Merge options on top of getDefaults() as a safeguard against options with
// unset values.
return ClangTidyOptions::getDefaults().merge(
- OptionsProvider->getOptions(File), 0);
+ *OptionsProvider->getOptions(File), 0);
----------------
galenelias wrote:
My analysis was that because clangTidyMain does the validation explicitly up
front and returns an error if it can't parse the config, that once it runs
through here, we are basically guaranteed that it will succeed, because the
errors have been caught.
However, digging in a bit deeper, I think there are at least two holes in this
understanding: clangTidyMain only pre-validates the config for the first file
passed in, so passing in a second file in a different directory with an invalid
configuration will crash here. The second is potentially the 'ClangTidyPlugin'
code, which seems to be another entry point into the clang tidy code that
bypasses clangTidyMain. I'm not sure what the ClangTidyPlugin is or how to
validate its behavior in the face of an invalid config.
I'll need to do a bit more digging to figure out the right strategy here. Just
bubbling up ErrorOr returns doesn't always seem great, but might unfortunately
be required.
https://github.com/llvm/llvm-project/pull/136167
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
