================
@@ -265,8 +265,16 @@ const ClangTidyOptions &ClangTidyContext::getOptions()
const {
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);
+ ClangTidyOptions defaultOptions = ClangTidyOptions::getDefaults();
+ llvm::ErrorOr<ClangTidyOptions> fileOptions =
+ OptionsProvider->getOptions(File);
+
+ // If there was an error parsing the options, just use the default options.
----------------
galenelias wrote:
I agree, but it seemed quite difficult to propagate an error from this function
and would drastically increase the size and invasiveness of this change, as
every call of this function would need to propagate the error, and so on and so
forth recursively until dozens+ of functions have been changed.
Given that in the primary clang-tidy usage scenario that these configs have
already been pre-validated, and that this fallback behavior is basically
equivalent to the previous behavior of silently continuing on with the default
config, this seemed like a reasonable compromise.
I can pursue propagating the error, but when I initially investigated it, it
seems quite complicated given the current places this method is called and how
prepared the callers were for propagating errors.
https://github.com/llvm/llvm-project/pull/136167
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
