[PATCH] D53280: [analyzer] Emit a warning for unknown -analyzer-config options

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

I agree with NoQ. Forward and backward compatibility might be important for CodeChecker as well.
But I wonder if it make sense to have analyzer-config compatibility mode on a per config basis?
E.g., if we have two configs:

- One did not exist in earlier clang versions, but a tool (like CodeChecker) would like to pass this to the analyzer without doing a version check first. Passing this in a compatibility mode makes sense. This could be the regural `-analyzer-config`
- The second option also did not exist in earlier clang versions, but we do not want to support those versions. In the case passing this config in a more strict mode makes sense. This could be something like `-analyzer-config-strict`.

Or we could choose the deafults the other way around.

What do you think? Does it make sense to have the compatibility mode on a per config bases or too much code for too little gain?



================
Comment at: include/clang/StaticAnalyzer/Core/AnalyzerOptions.h:323
+  std::vector<StringRef> getConfigOptionList() const {
+    return {
+#define ANALYZER_OPTION(TYPE, NAME, CMDFLAG, DESC) \
----------------
I wonder if it is worth to store this in a static object, have it sorted and use binary search for the warning. If we do not expect to have a lot more options in the future I am fine with the current solution.


https://reviews.llvm.org/D53280