[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL361552: [analyzer] Add a new frontend flag to display all 
checker options (authored by Szelethus, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57858?vs=199188=201056#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57858/new/

https://reviews.llvm.org/D57858

Files:
  cfe/trunk/include/clang/Driver/CC1Options.td
  cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  cfe/trunk/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  cfe/trunk/include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  cfe/trunk/lib/StaticAnalyzer/Frontend/CheckerRegistration.cpp
  cfe/trunk/lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
  cfe/trunk/test/Analysis/analyzer-checker-option-help.c
  cfe/trunk/test/Analysis/analyzer-list-configs.c
  cfe/trunk/test/Analysis/checker-plugins.c

Index: cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
@@ -166,6 +166,29 @@
   static std::vector
   getRegisteredCheckers(bool IncludeExperimental = false);
 
+  /// Convenience function for printing options or checkers and their
+  /// description in a formatted manner. If \p MinLineWidth is set to 0, no line
+  /// breaks are introduced for the description.
+  ///
+  /// Format, depending whether the option name's length is less then
+  /// \p OptionWidth:
+  ///
+  ///   EntryNameDescription
+  ///   <-padding->Description
+  ///   <-padding->Description
+  ///
+  ///   VeryVeryLongOptionName
+  ///   <-padding->Description
+  ///   <-padding->Description
+  ///   ^~~~ InitialPad
+  ///   ^~ EntryWidth
+  ///   ^~MinLineWidth
+  static void printFormattedEntry(
+  llvm::raw_ostream ,
+  std::pair EntryDescPair,
+  size_t EntryWidth, size_t InitialPad, size_t MinLineWidth = 0);
+
+
   /// Pair of checker name and enable/disable.
   std::vector> CheckersControlList;
 
@@ -199,6 +222,7 @@
   unsigned ShowCheckerHelp : 1;
   unsigned ShowCheckerHelpHidden : 1;
   unsigned ShowEnabledCheckerList : 1;
+  unsigned ShowCheckerOptionList : 1;
   unsigned ShowConfigOptionsList : 1;
   unsigned ShouldEmitErrorsOnInvalidConfigValue : 1;
   unsigned AnalyzeAll : 1;
@@ -262,11 +286,11 @@
   AnalyzerOptions()
   : DisableAllChecks(false), ShowCheckerHelp(false),
 ShowCheckerHelpHidden(false), ShowEnabledCheckerList(false),
-ShowConfigOptionsList(false), AnalyzeAll(false),
-AnalyzerDisplayProgress(false), AnalyzeNestedBlocks(false),
-eagerlyAssumeBinOpBifurcation(false), TrimGraph(false),
-visualizeExplodedGraphWithGraphViz(false), UnoptimizedCFG(false),
-PrintStats(false), NoRetryExhausted(false) {
+ShowCheckerOptionList(false), ShowConfigOptionsList(false),
+AnalyzeAll(false), AnalyzerDisplayProgress(false),
+AnalyzeNestedBlocks(false), eagerlyAssumeBinOpBifurcation(false),
+TrimGraph(false), visualizeExplodedGraphWithGraphViz(false),
+UnoptimizedCFG(false), PrintStats(false), NoRetryExhausted(false) {
 llvm::sort(AnalyzerConfigCmdFlags);
   }
 
Index: cfe/trunk/include/clang/StaticAnalyzer/Frontend/FrontendActions.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Frontend/FrontendActions.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Frontend/FrontendActions.h
@@ -61,6 +61,10 @@
  DiagnosticsEngine ,
  const LangOptions );
 void printAnalyzerConfigList(raw_ostream );
+void printCheckerConfigList(raw_ostream , ArrayRef plugins,
+AnalyzerOptions ,
+DiagnosticsEngine ,
+const LangOptions );
 
 } // end GR namespace
 
Index: cfe/trunk/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
===
--- cfe/trunk/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
+++ cfe/trunk/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
@@ -272,6 +272,7 @@
   void printCheckerWithDescList(raw_ostream ,
 size_t MaxNameChars = 30) const;
   void printEnabledCheckerList(raw_ostream ) const;
+  void printCheckerOptionList(raw_ostream ) const;
 
 private:
   /// 

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D57858#1502052 , @NoQ wrote:

> In D57858#1501065 , @dkrupp wrote:
>
> > These are the alpha checkers that we are testing in Ericsson:
>
>
> Hmm, if you don't mind i'll take this to cfe-dev, as it's an interesting 
> topic :)


Not at all, I started to feel like we're deviating from the patch discuasion 
quite badly anyways :)


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

http://lists.llvm.org/pipermail/cfe-dev/2019-May/062298.html


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D57858#1501065 , @dkrupp wrote:

> These are the alpha checkers that we are testing in Ericsson:


Hmm, if you don't mind i'll take this to cfe-dev, as it's an interesting topic 
:)


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Daniel Krupp via Phabricator via cfe-commits]

dkrupp added a comment.

In D57858#1500635 , @NoQ wrote:

> In D57858#146 , @dkrupp wrote:
>
> > Some alpha checkers are considerably more mature than others and are quite 
> > usable. In our experience, there are some users who are keen to run these 
> > checkers on their code and report back any false positives to us. So in 
> > this sense these are not "developer only" checkers. So I think we should 
> > let the users list them, read their descriptions and try them out. Some of 
> > them will come back with useful feedback as to how to improve them further.
>
>
> What are such checkers currently? Like, the ones that aren't clearly "missing 
> limbs" and that have somebody happy to //address// feedback sent against them?
>
> Do you have a chance to call out to your users for testing the checker and 
> actively request feedback, as @Szelethus did on the mailing list?
>
> I feel that we could do some sort of "early access checkers" programme, but i 
> believe this would require a more careful PR than just dumping a list of 
> alpha checkers on our users' heads.
>
> In D57858#146 , @dkrupp wrote:
>
> > Some users would not care if the checker gives some more false positives 
> > than the "mature" checkers if they can catch some true positives with them.
>
>
> Yeah, and these are pretty much the users we're trying to protect from 
> themselves :)


These are the alpha checkers that we are testing in Ericsson:
 alpha.core.BoolAssignment
 alpha.core.CastSize
 alpha.core.Conversion
 alpha.core.DynamicTypeChecker
 alpha.core.SizeofPtr
 alpha.core.TestAfterDivZero
 alpha.cplusplus.DeleteWithNonVirtualDtor
 alpha.cplusplus.MisusedMovedObject
 alpha.cplusplus.UninitializedObject
 alpha.security.MallocOverflow
 alpha.security.MmapWriteExec
 alpha.security.ReturnPtrRange
 alpha.security.taint.TaintPropagation
 alpha.unix.BlockInCriticalSection
 alpha.unix.Chroot
 alpha.unix.PthreadLock
 alpha.unix.SimpleStream
 alpha.unix.Stream
 alpha.unix.cstring.NotNullTerminated
 alpha.unix.cstring.OutOfBounds

This 2 have just been moved out of alpha lately:
 alpha.cplusplus.MisusedMovedObject
 alpha.cplusplus.UninitializedObject

According to our tests these checkers do not crash and do not give a large 
number of reports (<~50)  even on large code base.
So we can check for false positives in them one by one. 
Probably these are the closest to come out from alpha. 
We could maybe try to test these checkers one-by-one on large open source code 
bases and move them out from alpha when we are confident enough.


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D57858#1500635 , @NoQ wrote:

> In D57858#146 , @dkrupp wrote:
>
> > Some alpha checkers are considerably more mature than others and are quite 
> > usable. In our experience, there are some users who are keen to run these 
> > checkers on their code and report back any false positives to us. So in 
> > this sense these are not "developer only" checkers. So I think we should 
> > let the users list them, read their descriptions and try them out. Some of 
> > them will come back with useful feedback as to how to improve them further.
>
>
> What are such checkers currently? Like, the ones that aren't clearly "missing 
> limbs" and that have somebody happy to //address// feedback sent against them?


`IteratorChecker` is a prime example that still suffers from not ideal FP/TP 
ratio, but users at Ericsson value it plenty enough not to be bothered by it. 
Many of the changes here and in private directly address user bug reports 
(That's just one, but I do remember having others around too!).

> Do you have a chance to call out to your users for testing the checker and 
> actively request feedback, as @Szelethus did on the mailing list?

Actually yes! Experimental features, even if not checkers, such as the macro 
expansion thingy I wrote was very much feedback driven.

> I feel that we could do some sort of "early access checkers" programme, but i 
> believe this would require a more careful PR than just dumping a list of 
> alpha checkers on our users' heads.

How about making the `-analyzer-checker-help-alpha` flag only emit alpha 
checkers, surrounded by giant disclaimers, and adding some scary text to each 
checkers description?

  *** DISCLAIMER: Alpha checkers might be incomplet and inkorrekt, unstable and 
emit high amount of false positives! Use it as your own discretion! ***
  
alpha.cplusplus.ReinterpretCastIsBad  **EXPERIMENTAL, UNDER DEVELOPMENT** A 
checker that shames you for using reinterpret_cast.
alpha.optin.optout.Random **EXPERIMENTAL, UNDER DEVELOPMENT** 
This checker will cause a crash when enabled. Really.
alpha.pointless.Congrats  **EXPERIMENTAL, UNDER DEVELOPMENT** A 
checker that emits a report for each correct function pointer to function 
pointer C-style cast. Nice!
  
  *** DISCLAIMER: Alpha checkers might be incomplet and inkorrekt, unstable and 
emit high amount of false positives! Use it as your own discretion! ***


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D57858#146 , @dkrupp wrote:

> Some alpha checkers are considerably more mature than others and are quite 
> usable. In our experience, there are some users who are keen to run these 
> checkers on their code and report back any false positives to us. So in this 
> sense these are not "developer only" checkers. So I think we should let the 
> users list them, read their descriptions and try them out. Some of them will 
> come back with useful feedback as to how to improve them further.


What are such checkers currently? Like, the ones that aren't clearly "missing 
limbs" and that have somebody happy to //address// feedback sent against them?

Do you have a chance to call out to your users for testing the checker and 
actively request feedback, as @Szelethus did on the mailing list?

I feel that we could do some sort of "early access checkers" programme, but i 
believe this would require a more careful PR than just dumping a list of alpha 
checkers on our users' heads.

In D57858#146 , @dkrupp wrote:

> Some users would not care if the checker gives some more false positives than 
> the "mature" checkers if they can catch some true positives with them.


Yeah, and these are pretty much the users we're trying to protect from 
themselves :)


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Daniel Krupp via Phabricator via cfe-commits]

dkrupp added a comment.

In D57858#1499414 , @Szelethus wrote:

> In D57858#1498640 , @NoQ wrote:
>
> > So, like, the global picture is as follows. In our case the Driver (i.e., 
> > --analyze) is not much more user facing than frontend flags. It's still 
> > fairly unusable directly, as our Static Analyzer is generally not a 
> > command-line tool. The real user-facing stuff is the GUIs such as 
> > scan-build or CodeChecker. These GUIs decide themselves on what options 
> > they want to expose. For instance, you have a right to decide that 
> > CodeChecker shouldn't support the aggressive mode of the move-checker and 
> > don't expose it as an option in your GUI. In this sense it's not really 
> > useful to provide a centralized `-help` of all user-facing options.
> >
> > But it sounds as if you want to change this situation and provide a single 
> > source of truth on what are the user-facing options. Particular GUIs can 
> > still ignore them, but you don't want to hardcode flags in CodeChecker, but 
> > instead you want to rely on clang to provide the list of supported options 
> > for you and, as a side effect, for scan-build users (if you also add a 
> > scan-build help flag). I'm totally in favor of crystallizing such list of 
> > user-facing flags, and this patch sounds like a good step in that 
> > direction, assuming that non-user-facing options are hidden.
>
>
> That describes my intention quite well :)
>
> > I'm still in favor of hiding alpha checkers (as they are for development 
> > only, much like debug flags; i'd recommend hiding them in the CodeChecker 
> > UI as well)
> > 
> > Now, why do we care about frontend/driver flags when they're unusable by 
> > definition? That's because we have a mental trauma after seeing a few 
> > powerusers actively explore those flags, observe that they don't work, and 
> > then tell everybody that the Analyzer is broken. So there's a threshold, 
> > based on a tiny but painful bit of practical experience, that says that 
> > documentation of developer-only features on llvm.org or in code comments is 
> > fine, but documentation printed by the released binary itself is not fine.
>
> What you say sounds very reasonable. Still, I am kind of hesitant about 
> hiding all alpha checkers: I initially intended to hide only are 
> developer-only checkers (modeling, debug). I guess if we define alpha 
> checkers (as you stated numerous times) as incomplete, under development, are 
> missing half their limbs and crash if you look at them the wrong way, sure, 
> they belong in the developer-only category. But checkers such as mine 
> (UninitializedObjectChecker), for the longest time were very stable, have 
> been enabled by default for our internal projects, despite only recently 
> moving out of alpha.
>
> Then agaaain, if we're that stubborn about alpha checkers, we could might as 
> well dig them out of `-analyzer-checker-help-hidden`, and leave the rest 
> there. Untangling what alpha checkers depend on one another could be solved 
> by making yet another frontend flag that would display checker dependencies, 
> which would be super easy since D54438 , or 
> create an `-analyzer-checker-help-alpha` flag that would display alpha, but 
> not developer-only checkers. @dkrupp @o.gyorgy Do you have any feelings on 
> this?
>
> > and we should probably automatically hide options of checker that are 
> > hidden.
>
> Checker options are a different kind of animal entirely. I think we should 
> definitely let the user fine-tune some modeling checkers, for instance, 
> `unix.DynamicMemoryModeling:Optimistic`, despite us not really wanting to let 
>  anyone (even developers really) mess around whether 
> `unix.DynamicMemoryModeling` should be enabled. While that specific option 
> is, to put it nicely, a little esoteric, making some decisions the analyzer 
> makes less conservative, or limiting state splits to help performance may be 
> desirable in the future.
>
> Let's move the rest of the discussion directly related to hiding checker 
> options to D61839 !


Yes, it would be great if the clang static analyzer would be the ultimate 
source of information with respect to the checkers and checker options. Then we 
would not need to split this info between the front-end (scanbuild, 
codechecker) and the analyzer.

Some alpha checkers are considerably more mature than others and are quite 
usable. In our experience, there are some users who are keen to run these 
checkers on their code and report back any false positives to us. So in this 
sense these are not "developer only" checkers. So I think we should let the 
users list them, read their descriptions and try them out. Some of them will 
come back with useful feedback as to how to improve them further. Some users 
would not care if the checker gives some more false positives 

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a subscriber: o.gyorgy.
Szelethus added a comment.

In D57858#1498640 , @NoQ wrote:

> So, like, the global picture is as follows. In our case the Driver (i.e., 
> --analyze) is not much more user facing than frontend flags. It's still 
> fairly unusable directly, as our Static Analyzer is generally not a 
> command-line tool. The real user-facing stuff is the GUIs such as scan-build 
> or CodeChecker. These GUIs decide themselves on what options they want to 
> expose. For instance, you have a right to decide that CodeChecker shouldn't 
> support the aggressive mode of the move-checker and don't expose it as an 
> option in your GUI. In this sense it's not really useful to provide a 
> centralized `-help` of all user-facing options.
>
> But it sounds as if you want to change this situation and provide a single 
> source of truth on what are the user-facing options. Particular GUIs can 
> still ignore them, but you don't want to hardcode flags in CodeChecker, but 
> instead you want to rely on clang to provide the list of supported options 
> for you and, as a side effect, for scan-build users (if you also add a 
> scan-build help flag). I'm totally in favor of crystallizing such list of 
> user-facing flags, and this patch sounds like a good step in that direction, 
> assuming that non-user-facing options are hidden.


That describes my intention quite well :)

> I'm still in favor of hiding alpha checkers (as they are for development 
> only, much like debug flags; i'd recommend hiding them in the CodeChecker UI 
> as well)
> 
> Now, why do we care about frontend/driver flags when they're unusable by 
> definition? That's because we have a mental trauma after seeing a few 
> powerusers actively explore those flags, observe that they don't work, and 
> then tell everybody that the Analyzer is broken. So there's a threshold, 
> based on a tiny but painful bit of practical experience, that says that 
> documentation of developer-only features on llvm.org or in code comments is 
> fine, but documentation printed by the released binary itself is not fine.

What you say sounds very reasonable. Still, I am kind of hesitant about hiding 
all alpha checkers: I initially intended to hide checkers that are 
developer-only checkers (modeling, debug). I guess if we define alpha checkers 
(as you stated numerous times) as incomplete, under development checkers, that 
are missing half their limbs and crash if you look at them the wrong way, sure, 
they belong in the developer-only category. But checkers such as mine 
(UninitializedObjectChecker), for the longest time were very stable, have been 
enabled by default for our internal projects, despite only recently moving out 
of alpha.

Then agaaain, if we're that stubborn about alpha checkers, we could might as 
well dig them out of `-analyzer-checker-help`, and leave the rest there. 
Untangling what alpha checkers depend on one another could be solved by making 
yet another frontend flag that would display checker dependencies, which would 
be super easy since D54438 . @dkrupp @o.gyorgy 
Do you have any feelings on this?

> and we should probably automatically hide options of checker that are hidden.

Checker options are a different kind of animal entirely. think we should 
definitely let the user fine-tune some modeling checkers, for instance, 
`unix.DynamicMemoryModeling:Optimistic`, despite us not really wanting to let  
anyone (even developers really) mess around whether 
`unix.DynamicMemoryModeling` should be enabled. While that specific option is, 
to put it nicely, a little esoteric, making some decisions the analyzer makes 
less conservative, or limiting state splits to help performance may be 
desirable in the future.

Let's move the rest of the discussion directly related to hiding checker 
options to D61839 !


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D57858#1498651 , @NoQ wrote:

> Also, for CodeChecker purposes wouldn't you rather have a machine-readable 
> dump?


My main purpose was readability in the terminal, but I will need to think about 
that eventually. The current diff allows such formatting changes very easily, 
should CodeChecker have any issues, and I do like the output format as it is 
currently (as far as I know, clang-tidy check options are formatted similarly).


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus updated this revision to Diff 199188.
Szelethus added a comment.

- Make the educated observation that the code for formatted output is 
duplicated for `-analyzer-checker-help`, `-analyzer-config-help` and this 
patch, reuse it via the new static function 
`AnalyzerOptions::printFormattedEntry`.
- Remove the `USAGE` that suggested the use of the driver (did you mean to 
remove it entirely? Really, without reading test files, you'd never know how to 
use it)
- Hide certain options by default, implemented in a followup patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57858/new/

https://reviews.llvm.org/D57858

Files:
  include/clang/Driver/CC1Options.td
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  lib/Frontend/CompilerInvocation.cpp
  lib/FrontendTool/ExecuteCompilerInvocation.cpp
  lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  lib/StaticAnalyzer/Frontend/CheckerRegistration.cpp
  lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
  test/Analysis/analyzer-checker-option-help.c
  test/Analysis/analyzer-list-configs.c
  test/Analysis/checker-plugins.c

Index: test/Analysis/checker-plugins.c
===
--- test/Analysis/checker-plugins.c
+++ test/Analysis/checker-plugins.c
@@ -104,3 +104,12 @@
 // RUN:   2>&1 | FileCheck %s -check-prefix=CHECK-CORRECTED-BOOL-VALUE
 
 // CHECK-CORRECTED-BOOL-VALUE: example.MyChecker:ExampleOption = false
+
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -load %llvmshlibdir/CheckerOptionHandlingAnalyzerPlugin%pluginext\
+// RUN:   -analyzer-checker=example.MyChecker \
+// RUN:   -analyzer-checker-option-help \
+// RUN:   2>&1 | FileCheck %s -check-prefix=CHECK-CHECKER-OPTION-HELP
+
+// CHECK-CHECKER-OPTION-HELP: example.MyChecker:ExampleOption  (bool) This is an
+// CHECK-CHECKER-OPTION-HELP-SAME: example checker opt. (default: false)
Index: test/Analysis/analyzer-list-configs.c
===
--- test/Analysis/analyzer-list-configs.c
+++ test/Analysis/analyzer-list-configs.c
@@ -1,14 +1,11 @@
 // RUN: %clang_cc1 -analyzer-config-help 2>&1 | FileCheck %s
+
 // CHECK: OVERVIEW: Clang Static Analyzer -analyzer-config Option List
 //
-// CHECK: USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config 
-//
-// CHECK:  clang -cc1 [CLANG_OPTIONS] -analyzer-config OPTION1=VALUE, -analyzer-config OPTION2=VALUE, ...
-//
-// CHECK:  clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang
-//
-// CHECK:  clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang OPTION1=VALUE, -Xclang -analyzer-config -Xclang OPTION2=VALUE, ...
+// CHECK: USAGE: -analyzer-config 
 //
+// CHECK:-analyzer-config OPTION1=VALUE, -analyzer-config
+// CHECK-SAME:   OPTION2=VALUE, ...
 //
 // CHECK: OPTIONS:
 //
Index: test/Analysis/analyzer-checker-option-help.c
===
--- /dev/null
+++ test/Analysis/analyzer-checker-option-help.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -analyzer-checker-option-help 2>&1 | FileCheck %s
+
+// CHECK: OVERVIEW: Clang Static Analyzer Checker and Package Option List
+//
+// CHECK: USAGE: -analyzer-config 
+//
+// CHECK:-analyzer-config OPTION1=VALUE, -analyzer-config
+// CHECK-SAME:   OPTION2=VALUE, ...
+//
+// CHECK: OPTIONS:
+//
+// CHECK:   alpha.clone.CloneChecker:MinimumCloneComplexity
+// CHECK-SAME:   (int) Ensures that every clone has at least
+// CHECK:the given complexity. Complexity is here
+// CHECK:defined as the total amount of children
+// CHECK:of a statement. This constraint assumes
+// CHECK:the first statement in the group is representative
+// CHECK:for all other statements in the group in
+// CHECK:terms of complexity. (default: 50)
Index: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
===
--- lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
+++ lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
@@ -518,17 +518,8 @@
 if (!AnOpts.ShowCheckerHelpHidden && Checker.IsHidden)
   continue;
 
-Out.indent(InitialPad) << Checker.FullName;
-
-int Pad = OptionFieldWidth - Checker.FullName.size();
-
-// Break on long option names.
-if (Pad < 0) {
-  Out << '\n';
-  Pad = OptionFieldWidth + InitialPad;
-}
-Out.indent(Pad + 2) << Checker.Desc;
-
+AnalyzerOptions::printFormattedEntry(Out, {Checker.FullName, Checker.Desc},
+ InitialPad, OptionFieldWidth);
 Out << '\n';
   }
 }
@@ -540,3 +531,41 @@
   for (const auto *i : EnabledCheckers)
 Out << i->FullName << '\n';
 }
+
+void CheckerRegistry::printCheckerOptionList(raw_ostream ) const {
+  Out << "OVERVIEW: Clang Static Analyzer Checker and Package Option List\n\n";
+  Out << "USAGE: -analyzer-config \n\n";

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Also, for CodeChecker purposes wouldn't you rather have a machine-readable dump?


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Let's land this together with @Szelethus's proposed solution of hiding hidden 
options (like checkers in D60925 ). I'm still 
in favor of hiding alpha checkers (as they are for development only, much like 
debug flags; i'd recommend hiding them in the CodeChecker UI as well) and we 
should probably automatically hide options of checker that are hidden. Let's 
also, indeed, remove the USAGE thingy as it doesn't add much.

So, like, the global picture is as follows. In our case the Driver (i.e., 
--analyze) is not much more user facing than frontend flags. It's still fairly 
unusable directly, as our Static Analyzer is generally not a command-line tool. 
The real user-facing stuff is the GUIs such as scan-build or CodeChecker. These 
GUIs decide themselves on what options they want to expose. For instance, you 
have a right to decide that CodeChecker shouldn't support the aggressive mode 
of the move-checker and don't expose it as an option in your GUI. In this sense 
it's not really useful to provide a centralized `-help` of all user-facing 
options.

But it sounds as if you want to change this situation and provide a single 
source of truth on what are the user-facing options. Particular GUIs can still 
ignore them, but you don't want to hardcode flags in CodeChecker, but instead 
you want to rely on clang to provide the list of supported options for you and, 
as a side effect, for scan-build users (if you also add a scan-build help 
flag). I'm totally in favor of crystallizing such list of user-facing flags, 
and this patch sounds like a good step in that direction, assuming that 
non-user-facing options are hidden.

Now, why do we care about frontend/driver flags when they're unusable by 
definition? That's because we have a mental trauma after seeing a few 
powerusers actively explore those flags, observe that they don't work, and then 
tell everybody that the Analyzer is broken. So there's a threshold, based on a 
tiny but painful bit of practical experience, that says that documentation of 
developer-only features on llvm.org or in code comments is fine, but 
documentation printed by the released binary itself is not fine.


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

Ping^4


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus requested review of this revision.
Szelethus added a comment.

Similarly to D60925 , I plan to make a patch 
that will hide most the implementation options.


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Whisperity via Phabricator via cfe-commits]

whisperity added a comment.

@dcoughlin How would removing the `USAGE` part of the dump and keeping only the 
list of options and their formatted help sound? That way, this option will not 
invite the user to directly call the analyzer.

In D57858#1432714 , @dcoughlin wrote:

> - 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.


Calling this option itself, at least based on the original commit's first line, 
is through `-cc1`, and thus using a "checker/SA developer interface". This 
seems more purely as a tooling help, which as expressed by @dkrupp earlier, is 
helpful for "wrangler tools".

@Szelethus From a CodeChecker guy's perspective, I am a bit scared about the 
size this dump can get assuming every option is given a description/help text 
nicely, but all in all I like the direction of this patch.




Comment at: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp:584-592
+  Out << "USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config "
+
"\n\n";
+  Out << "   clang -cc1 [CLANG_OPTIONS] -analyzer-config OPTION1=VALUE, "
+  "-analyzer-config OPTION2=VALUE, 
...\n\n";
+  Out << "   clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang"
+
"\n\n";
+  Out << "   clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang "

(I mean killing these lines.)


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

Ping^3


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

Ping^2


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

Ping.


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Daniel Krupp via Phabricator via cfe-commits]

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 , @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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

This patch isn't intended for end users, which is why 
`-analyzer-checker-option-help` is a frontend flag -- besides, some of the 
plain frontend flags aren't either. It is purely for development purposes, 
though exposing an end user friendly subset of these through a driver flag 
would be cool.


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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin requested changes to this revision.
dcoughlin added a comment.
This revision now requires changes to proceed.

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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus updated this revision to Diff 190997.
Szelethus added a comment.

Add a test case for then checker plugin.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57858/new/

https://reviews.llvm.org/D57858

Files:
  include/clang/Driver/CC1Options.td
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  lib/Frontend/CompilerInvocation.cpp
  lib/FrontendTool/ExecuteCompilerInvocation.cpp
  lib/StaticAnalyzer/Frontend/CheckerRegistration.cpp
  lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
  test/Analysis/analyzer-checker-option-help.c
  test/Analysis/checker-plugins.c

Index: test/Analysis/checker-plugins.c
===
--- test/Analysis/checker-plugins.c
+++ test/Analysis/checker-plugins.c
@@ -104,3 +104,12 @@
 // RUN:   2>&1 | FileCheck %s -check-prefix=CHECK-CORRECTED-BOOL-VALUE
 
 // CHECK-CORRECTED-BOOL-VALUE: example.MyChecker:ExampleOption = false
+
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -load %llvmshlibdir/OptionHandlingAnalyzerPlugin%pluginext\
+// RUN:   -analyzer-checker=example.MyChecker \
+// RUN:   -analyzer-checker-option-help \
+// RUN:   2>&1 | FileCheck %s -check-prefix=CHECK-CHECKER-OPTION-HELP
+
+// CHECK-CHECKER-OPTION-HELP: example.MyChecker:ExampleOption  (bool) This is an
+// CHECK-CHECKER-OPTION-HELP-SAME: example checker opt. (default: false)
Index: test/Analysis/analyzer-checker-option-help.c
===
--- /dev/null
+++ test/Analysis/analyzer-checker-option-help.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -analyzer-checker-option-help 2>&1 | FileCheck %s
+
+// CHECK: OVERVIEW: Clang Static Analyzer Checker and Package Option List
+//
+// CHECK: USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config 
+//
+// CHECK:clang -cc1 [CLANG_OPTIONS] -analyzer-config OPTION1=VALUE,
+// CHECK-SAME: -analyzer-config OPTION2=VALUE, ...
+//
+// CHECK:clang [CLANG_OPTIONS] -Xclang -analyzer-config
+// CHECK-SAME: -Xclang
+//
+// CHECK:clang [CLANG_OPTIONS] -Xclang -analyzer-config
+// CHECK-SAME: -Xclang OPTION1=VALUE, -Xclang -analyzer-config
+// CHECK-SAME: -Xclang OPTION2=VALUE, ...
+//
+// CHECK: OPTIONS:
+//
+// CHECK:   alpha.clone.CloneChecker:MinimumCloneComplexity  
+// CHECK-SAME:   (int) Ensures that every clone has at least
+// CHECK:the given complexity. Complexity is here
+// CHECK:defined as the total amount of children
+// CHECK:of a statement. This constraint assumes
+// CHECK:the first statement in the group is representative
+// CHECK:for all other statements in the group in
+// CHECK:terms of complexity. (default: 50)
Index: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
===
--- lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
+++ lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
@@ -19,6 +19,7 @@
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/DynamicLibrary.h"
+#include "llvm/Support/FormattedStream.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -538,3 +539,75 @@
   for (const auto *i : EnabledCheckers)
 Out << i->FullName << '\n';
 }
+
+// Some global constants to help with printing.
+constexpr size_t MinLineWidth = 90;
+constexpr size_t PadForOpt = 2;
+constexpr size_t OptionWidth = 50;
+constexpr size_t PadForDesc = PadForOpt + OptionWidth;
+static_assert(MinLineWidth > PadForDesc, "MinLineWidth must be greater!");
+
+static void printCmdLineOption(llvm::formatted_raw_ostream ,
+   StringRef CheckerOrPackageFullName,
+   const CheckerRegistry::CmdLineOption ) {
+  FOut.PadToColumn(PadForOpt) << CheckerOrPackageFullName << ':'
+  << Option.OptionName;
+
+  // If the buffer's length is greater then PadForDesc, print a newline.
+  if (FOut.getColumn() > PadForDesc)
+FOut << '\n';
+
+  FOut.PadToColumn(PadForDesc) << "(" << Option.OptionType << ") ";
+
+  for (char C : Option.Description) {
+if (FOut.getColumn() > MinLineWidth && C == ' ') {
+  FOut << '\n';
+  FOut.PadToColumn(PadForDesc);
+  continue;
+}
+FOut << C;
+  }
+
+  if (!Option.Description.empty())
+FOut << ' ';
+  if (FOut.getColumn() > MinLineWidth) {
+FOut << '\n';
+FOut.PadToColumn(PadForDesc);
+  }
+  FOut << "(default: "
+   << (Option.DefaultValStr.empty() ? "\"\"" : Option.DefaultValStr)
+   << ")\n\n";
+}
+
+void CheckerRegistry::printCheckerOptionList(raw_ostream ) const {
+  Out << "OVERVIEW: Clang Static Analyzer Checker and Package Option List\n\n";
+  Out << "USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config "
+ 

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus updated this revision to Diff 190625.
Szelethus edited the summary of this revision.
Szelethus added a comment.
Herald added subscribers: Charusso, jdoerfert.

Also, don't forget package options :^)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57858/new/

https://reviews.llvm.org/D57858

Files:
  include/clang/Driver/CC1Options.td
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h
  include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  lib/Frontend/CompilerInvocation.cpp
  lib/FrontendTool/ExecuteCompilerInvocation.cpp
  lib/StaticAnalyzer/Frontend/CheckerRegistration.cpp
  lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
  test/Analysis/analyzer-checker-option-help.c

Index: test/Analysis/analyzer-checker-option-help.c
===
--- /dev/null
+++ test/Analysis/analyzer-checker-option-help.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -analyzer-checker-option-help 2>&1 | FileCheck %s
+
+// CHECK: OVERVIEW: Clang Static Analyzer Checker and Package Option List
+//
+// CHECK: USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config 
+//
+// CHECK:clang -cc1 [CLANG_OPTIONS] -analyzer-config OPTION1=VALUE,
+// CHECK-SAME: -analyzer-config OPTION2=VALUE, ...
+//
+// CHECK:clang [CLANG_OPTIONS] -Xclang -analyzer-config
+// CHECK-SAME: -Xclang
+//
+// CHECK:clang [CLANG_OPTIONS] -Xclang -analyzer-config
+// CHECK-SAME: -Xclang OPTION1=VALUE, -Xclang -analyzer-config
+// CHECK-SAME: -Xclang OPTION2=VALUE, ...
+//
+// CHECK: OPTIONS:
+//
+// CHECK:   alpha.clone.CloneChecker:MinimumCloneComplexity  
+// CHECK-SAME:   (int) Ensures that every clone has at least
+// CHECK:the given complexity. Complexity is here
+// CHECK:defined as the total amount of children
+// CHECK:of a statement. This constraint assumes
+// CHECK:the first statement in the group is representative
+// CHECK:for all other statements in the group in
+// CHECK:terms of complexity. (default: 50)
Index: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
===
--- lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
+++ lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
@@ -515,3 +515,75 @@
   for (const auto *i : enabledCheckers)
 Out << i->FullName << '\n';
 }
+
+// Some global constants to help with printing.
+constexpr size_t MinLineWidth = 90;
+constexpr size_t PadForOpt = 2;
+constexpr size_t OptionWidth = 50;
+constexpr size_t PadForDesc = PadForOpt + OptionWidth;
+static_assert(MinLineWidth > PadForDesc, "MinLineWidth must be greater!");
+
+static void printCmdLineOption(llvm::formatted_raw_ostream ,
+   StringRef CheckerOrPackageFullName,
+   const CheckerRegistry::CmdLineOption ) {
+  FOut.PadToColumn(PadForOpt) << CheckerOrPackageFullName << ':'
+  << Option.OptionName;
+
+  // If the buffer's length is greater then PadForDesc, print a newline.
+  if (FOut.getColumn() > PadForDesc)
+FOut << '\n';
+
+  FOut.PadToColumn(PadForDesc) << "(" << Option.OptionType << ") ";
+
+  for (char C : Option.Description) {
+if (FOut.getColumn() > MinLineWidth && C == ' ') {
+  FOut << '\n';
+  FOut.PadToColumn(PadForDesc);
+  continue;
+}
+FOut << C;
+  }
+
+  if (!Option.Description.empty())
+FOut << ' ';
+  if (FOut.getColumn() > MinLineWidth) {
+FOut << '\n';
+FOut.PadToColumn(PadForDesc);
+  }
+  FOut << "(default: "
+   << (Option.DefaultValStr.empty() ? "\"\"" : Option.DefaultValStr)
+   << ")\n\n";
+}
+
+void CheckerRegistry::printCheckerOptionList(raw_ostream ) const {
+  Out << "OVERVIEW: Clang Static Analyzer Checker and Package Option List\n\n";
+  Out << "USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config "
+"\n\n";
+  Out << "   clang -cc1 [CLANG_OPTIONS] -analyzer-config OPTION1=VALUE, "
+  "-analyzer-config OPTION2=VALUE, ...\n\n";
+  Out << "   clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang"
+"\n\n";
+  Out << "   clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang "
+  "OPTION1=VALUE, -Xclang -analyzer-config -Xclang "
+  "OPTION2=VALUE, ...\n\n";
+  Out << "OPTIONS:\n\n";
+
+  llvm::formatted_raw_ostream FOut(Out);
+
+  std::multimap OptionMap;
+
+  for (const CheckerInfo  : Checkers) {
+for (const CmdLineOption  : Checker.CmdLineOptions) {
+  OptionMap.insert({Checker.FullName, Option});
+}
+  }
+
+  for (const PackageInfo  : Packages) {
+for (const CmdLineOption  : Package.CmdLineOptions) {
+  OptionMap.insert({Package.FullName, 

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Artem Dergachev via Phabricator via cfe-commits]

NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

I think this is awesome!


Repository:
  rC Clang

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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus created this revision.
Szelethus added reviewers: NoQ, george.karpenkov, xazax.hun, rnkovacs, 
baloghadamsoftware.
Herald added subscribers: cfe-commits, gamesh411, dkrupp, donat.nagy, 
mikhail.ramalho, a.sidorin, szepet, kristof.beyls, whisperity, javed.absar.
Herald added a project: clang.
Szelethus added a parent revision: D57855: [analyzer] Reimplement checker 
options.

Title says it all, here is how it looks like locally:

  OVERVIEW: Clang Static Analyzer Checker Option List
  
  USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config 

  
 clang -cc1 [CLANG_OPTIONS] -analyzer-config OPTION1=VALUE, 
-analyzer-config OPTION2=VALUE, ...
  
 clang [CLANG_OPTIONS] -Xclang -analyzer-config 
-Xclang
  
 clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang OPTION1=VALUE, 
-Xclang -analyzer-config -Xclang OPTION2=VALUE, ...
  
  OPTIONS:
  
alpha.clone.CloneChecker:MinimumCloneComplexity   (int) Ensures that every 
clone has at least
  the given complexity. 
Complexity is here
  defined as the total 
amount of children
  of a statement. This 
constraint assumes
  the first statement in 
the group is representative
  for all other statements 
in the group in
  terms of complexity. 
(default: 50)
  
alpha.clone.CloneChecker:ReportNormalClones   (bool) Report all clones, 
even less suspicious
  ones. (default: true)
  
alpha.clone.CloneChecker:IgnoredFilesPattern  (string) If supplied, the 
checker wont analyze
  files with a filename 
that matches the given
  pattern. (default: "")
  
alpha.cplusplus.UninitializedObject:Pedantic  (bool) If set to false, 
the checker won't
  emit warnings for objects 
that don't have
  at least one initialized 
field. (default: false)
  
alpha.cplusplus.UninitializedObject:NotesAsWarnings
  (bool) If set to true, 
the checker will
  emit a warning for each 
uninitalized field,
  as opposed to emitting 
one warning per constructor
  call, and listing the 
uninitialized fields
  that belongs to it in 
notes. (default: false)
  
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization
  (bool) If set to false, 
the checker will
  not analyze the pointee 
of pointer/reference
  fields, and will only 
check whether the
  object itself is 
initialized. (default: false)
  
alpha.cplusplus.UninitializedObject:IgnoreRecordsWithField
  (string) If supplied, the 
checker will not
  analyze structures that 
have a field with
  a name or type name that 
matches the given
  pattern. (default: "")
  
alpha.cplusplus.UninitializedObject:IgnoreGuardedFields
  (bool) If set to true, 
the checker will
  analyze _syntactically_ 
whether the found
  uninitialized object is 
used without a preceding
  assert call. Defaults to 
false. (default: false)
  
alpha.security.MmapWriteExec:MmapProtExec (int) Specifies the value 
of PROT_EXEC 
  (default: 0x04)
  
alpha.security.MmapWriteExec:MmapProtRead (int) Specifies the value 
of PROT_READ 
  (default: 0x01)
  
cplusplus.Move:WarnOn (string) In 
non-aggressive mode, only warn
  on use-after-move of 
local variables (or
  local rvalue references) 
and of STL objects.
  The former is possible 
because local variables