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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
