This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Add a new frontend flag to display all checker options
ClosedPublic

Authored by Szelethus on Feb 6 2019, 3:48 PM.

Details

Summary

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

clang -cc1 -analyzer-checker-option-help
OVERVIEW: Clang Static Analyzer Checker and Package Option List

USAGE: clang -cc1 [CLANG_OPTIONS] -analyzer-config <OPTION1=VALUE,OPTION2=VALUE,...>

       clang -cc1 [CLANG_OPTIONS] -analyzer-config OPTION1=VALUE, -analyzer-config OPTION2=VALUE, ...

       clang [CLANG_OPTIONS] -Xclang -analyzer-config -Xclang<OPTION1=VALUE,OPTION2=VALUE,...>

       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
                                                    (or local rvalue references) are not tempting
                                                    their user to re-use the storage. The latter
                                                    is possible because STL objects are known
                                                    to end up in a valid but unspecified state
                                                    after the move and their state-reset methods
                                                    are also known, which allows us to predict
                                                    precisely when use-after-move is invalid.
                                                    Some STL objects are known to conform to
                                                    additional contracts after move, so they
                                                    are not tracked. However, smart pointers
                                                    specifically are tracked because we can
                                                    perform extra checking over them. In aggressive
                                                    mode, warn on any use-after-move because
                                                    the user has intentionally asked us to completely
                                                    eliminate use-after-move in his code. Values:
                                                    "KnownsOnly", "KnownsAndLocals", "All". 
                                                    (default: KnownsAndLocals)

  debug.AnalysisOrder:PreStmtCastExpr               (bool) (default: false)

  debug.AnalysisOrder:PostStmtCastExpr              (bool) (default: false)

  debug.AnalysisOrder:PreStmtArraySubscriptExpr     (bool) (default: false)

  debug.AnalysisOrder:PostStmtArraySubscriptExpr    (bool) (default: false)

  debug.AnalysisOrder:PreStmtCXXNewExpr             (bool) (default: false)

  debug.AnalysisOrder:PostStmtCXXNewExpr            (bool) (default: false)

  debug.AnalysisOrder:PreStmtOffsetOfExpr           (bool) (default: false)

  debug.AnalysisOrder:PostStmtOffsetOfExpr          (bool) (default: false)

  debug.AnalysisOrder:PreCall                       (bool) (default: false)

  debug.AnalysisOrder:PostCall                      (bool) (default: false)

  debug.AnalysisOrder:EndFunction                   (bool) (default: false)

  debug.AnalysisOrder:NewAllocator                  (bool) (default: false)

  debug.AnalysisOrder:Bind                          (bool) (default: false)

  debug.AnalysisOrder:LiveSymbols                   (bool) (default: false)

  debug.AnalysisOrder:RegionChanges                 (bool) (default: false)

  debug.AnalysisOrder:*                             (bool) Enables all callbacks. (default: false)

  nullability:NoDiagnoseCallsToSystemHeaders        (bool) (default: false)

  optin.cplusplus.VirtualCall:PureOnly              (bool) Whether to only report calls to pure
                                                    virtual methods. (default: false)

  optin.osx.cocoa.localizability.NonLocalizedStringChecker:AggressiveReport
                                                    (bool) Marks a string being returned by
                                                    any call as localized if it is in LocStringFunctions
                                                    (LSF) or the function is annotated. Otherwise,
                                                    we mark it as NonLocalized (Aggressive)
                                                    or NonLocalized only if it is not backed
                                                    by a SymRegion (Non-Aggressive), basically
                                                    leaving only string literals as NonLocalized. 
                                                    (default: false)

  optin.performance.Padding:AllowedPad              (int) Reports are only generated if the
                                                    excessive padding exceeds 'AllowedPad' in
                                                    bytes. (default: 24)

  osx.NumberObjectConversion:Pedantic               (bool) Enables detection of more conversion
                                                    patterns (which are most likely more harmless,
                                                    and therefore are more likely to produce
                                                    false positives). (default: false)

  osx.cocoa.RetainCount:leak-diagnostics-reference-allocation
                                                    (bool) (default: false)

  osx.cocoa.RetainCount:CheckOSObject               (bool) (default: true)

  osx.cocoa.RetainCount:TrackNSCFStartParam         (bool) (default: false)

  unix.DynamicMemoryModeling:Optimistic             (bool) If set to true, the checker assumes
                                                    that all the allocating and deallocating
                                                    functions are annotated with ownership_holds,
                                                    ownership_takes and ownership_returns. 
                                                    (default: false)

Diff Detail

Repository
rL LLVM

Event Timeline

Szelethus created this revision.Feb 6 2019, 3:48 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 6 2019, 3:48 PM
NoQ accepted this revision.Feb 8 2019, 6:25 PM

I think this is awesome!

This revision is now accepted and ready to land.Feb 8 2019, 6:25 PM
Szelethus updated this revision to Diff 190625.Mar 14 2019, 7:31 AM
Szelethus edited the summary of this revision. (Show Details)

Also, don't forget package options :^)

Szelethus updated this revision to Diff 190997.Mar 16 2019, 1:06 PM

Add a test case for then checker plugin.

dcoughlin requested changes to this revision.Mar 17 2019, 8:06 PM

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.
This revision now requires changes to proceed.Mar 17 2019, 8:06 PM

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.

Szelethus edited the summary of this revision. (Show Details)Mar 26 2019, 6:55 AM

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

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.

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

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

lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp
584–592 ↗(On Diff #190997)

(I mean killing these lines.)

Szelethus requested review of this revision.Apr 30 2019, 4:33 AM

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

NoQ added a comment.May 10 2019, 2:30 PM

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.

NoQ added a comment.May 10 2019, 2:33 PM

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

Szelethus updated this revision to Diff 199188.May 12 2019, 3:48 PM
  • 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.
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).

Szelethus added a subscriber: o.gyorgy.
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!

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 than the "mature" checkers if they can catch some true positives with them.

@Szelethus has a good point in supporting three checker and option categories
-stable: checkers that are stable and which report "small number of false positives". (-analyzer-checker-help)
-experimental: checkers in alpha stage, with more false positives than usual, but which still should not crash. (-analyzer-checker-help-experimental or -analyzer-checker-help-alpha or -analyzer-checker-help-hidden ). We can add a disclaimer for this option.
-developer: modeling checkers, debug checkers that is used by checker/analyzer developer (-analyzer-checker-help-devel)

we could create the same help categories for checker options and non-checker configuration.

NoQ added a comment.May 13 2019, 2:59 PM

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.

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 :)

Szelethus added a comment.EditedMay 13 2019, 3:31 PM
In D57858#1500635, @NoQ 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 void* 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! ***
dkrupp added a comment.EditedMay 14 2019, 4:40 AM
In D57858#1500635, @NoQ 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.

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

These 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.
Probably these are the closest to come out from alpha.
So we can check for false positives in them one by one on large open source projects and move them out from alpha when we are confident enough in the quality.

NoQ added a comment.May 14 2019, 2:20 PM

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 :)

Szelethus added a comment.EditedMay 15 2019, 2:24 AM
In D57858#1502052, @NoQ 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 discussion quite badly anyways :)

This revision was not accepted when it landed; it landed in state Needs Review.May 23 2019, 1:45 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2019, 1:45 PM