dkrupp added a comment. @dcoughlin I don't necessarily agree with you. Let me explain why we think this feature is important.
We should give the users the possibility to list all possibly configurable checker options and their meaning. Many of these options should be possible to be set by the end user to be able to fine tune the checker behaviour to match the analyzed code style. Such examples are: alpha.clone.CloneChecker:MinimumCloneComplexity alpha.cplusplus.UninitializedObject:CheckPointeeInitialization alpha.clone.CloneChecker:ReportNormalClones alpha.cplusplus.UninitializedObject:IgnoreRecordsWithField etc. Actually except for the debug checker options and unix.DynamicMemoryModeling:Optimistic all these options are meaningful end-user options. Of course there are the debug checker options which are not interesting for the end user, but debug checkers should anyway be ignored by the end-users. We always wanted to add checker option listing to CodeChecker, however did not want to duplicate the option list and option documentation in the CodeChecker codebase. It belongs to the analyzer and actually to the checker implementation. So from CodeChecker we would like to invoke the "clang -cc1 -analyzer-checker-option-help" to be able to list these options to the end users. The same feature is available already in clang-tidy: clang-tidy -dump-config I think it is the responsibility of the end-user to decide what option he may want to configure. I understand you would like to differentiate between "developer" and "end-user" options. What we could do maybe is to indicate in the option explanation that the given option is "analyzer-internal", "experimental" or "developer only". What do you think about that? In D57858#1432714 <https://reviews.llvm.org/D57858#1432714>, @dcoughlin wrote: > I'm pretty worried about exposing this flag to end users. > > - Almost none of the options you've listed are user facing. Many represent > options intended for use by static analyzer developers: debugging options, > feature flags, and checkers that were never finished. Others represent > mechanisms for build systems to control the behavior of the analyzer. Even > these are not meant for end users to interact with but rather for > implementers of build systems and IDEs. I don't think end users should have > to understand these options to use the analyzer. > - The help text refers to analyzer implementation details (such as > "SymRegion") that users won't have the context or knowledge to understand. > - The help text also recommends invoking -cc1 directly or through the driver > with -Xclang. Neither of these are supported end-user interfaces to the > analyzer. Instead, users should use scan-build or another tool (such as > CodeChecker) that was designed to be used by humans. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57858/new/ https://reviews.llvm.org/D57858 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
