Szelethus planned changes to this revision.
Szelethus added a comment.
Since I've dug myself quite deep into the refactoring effort, I realized that
there are more elegant ways of achieving this, should I hammer
`AnalyzerOptions` for long enough. I'll probably change everything but the
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
NoQ added a comment.
Herald added a subscriber: dkrupp.
I guess we should consider the idea in
http://lists.llvm.org/pipermail/cfe-dev/2018-October/059864.html
Comment at: lib/Frontend/CompilerInvocation.cpp:343
}
+ // Check whether this really is a valid
Szelethus updated this revision to Diff 169693.
https://reviews.llvm.org/D53280
Files:
include/clang/Basic/DiagnosticDriverKinds.td
include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
lib/Frontend/CompilerInvocation.cpp
Index: lib/Frontend/CompilerInvocation.cpp
Szelethus added a comment.
@whisperity @xazax.hun A worry of mine is shared libraries, for example, we've
got an array of Ericsson-specific checkers that we load run-time. Do we support
(or should we) support acquiring non-checker `-analyzer-config` options?
Repository:
rC Clang
Szelethus created this revision.
Szelethus added reviewers: NoQ, george.karpenkov, xazax.hun, rnkovacs, MTC.
Herald added subscribers: cfe-commits, donat.nagy, mikhail.ramalho, a.sidorin,
szepet, whisperity.
I'm in the process of refactoring AnalyzerOptions. The main motivation behind
here is
