maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Analysis/analyzer-config.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

122 lines
6.3 KiB
C
Raw Normal View History

[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// RUN: %clang_analyze_cc1 -analyzer-checker=debug.ConfigDumper > %t 2>&1
[analyzer] Switch the default exploration strategy to priority queue based on coverage After the investigation it seems safe to flip the switch. Differential Revision: https://reviews.llvm.org/D43782 llvm-svn: 326157
2018-02-27 09:31:56 +08:00
// RUN: FileCheck --input-file=%t %s --match-full-lines
Have AnalyzerOptions::getBooleanOption() stick the matching config string in the config table so that it can be dumped as part of the config dumper. Add a test to show that these options are sticking and can be cross-checked using FileCheck. llvm-svn: 164954
2012-10-02 02:28:19 +08:00
[analyzer][CallAndMessage] Add checker options for each bug type iAs listed in the summary D77846, we have 5 different categories of bugs we're checking for in CallAndMessage. I think the documentation placed in the code explains my thought process behind my decisions quite well. A non-obvious change I had here is removing the entry for CallAndMessageUnInitRefArg. In fact, I removed the CheckerNameRef typed field back in D77845 (it was dead code), so that checker didn't really exist in any meaningful way anyways. Differential Revision: https://reviews.llvm.org/D77866
2020-04-06 01:53:22 +08:00
// CHECK: [config]
[analyzer] [NFC] PathDiagnostic: Create PathDiagnosticPopUpPiece Summary: This new piece is similar to our macro expansion printing in HTML reports: On mouse-hover event it pops up on variables. Similar to note pieces it supports `plist` diagnostics as well. It is optional, on by default: `add-pop-up-notes=true`. Extra: In HTML reports `background-color: LemonChiffon` was too light, changed to `PaleGoldenRod`. Reviewers: NoQ, alexfh Reviewed By: NoQ Subscribers: cfe-commits, gerazo, gsd, george.karpenkov, alexfh, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D60670 llvm-svn: 362014
2019-05-30 03:21:59 +08:00
// CHECK-NEXT: add-pop-up-notes = true
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: aggressive-binary-operation-simplification = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: alpha.clone.CloneChecker:IgnoredFilesPattern = ""
// CHECK-NEXT: alpha.clone.CloneChecker:MinimumCloneComplexity = 50
// CHECK-NEXT: alpha.clone.CloneChecker:ReportNormalClones = true
[Analyzer] Model STL Algoirthms to improve the iterator checkers STL Algorithms are usually implemented in a tricky for performance reasons which is too complicated for the analyzer. Furthermore inlining them is costly. Instead of inlining we should model their behavior according to the specifications. This patch is the first step towards STL Algorithm modeling. It models all the `find()`-like functions in a simple way: the result is either found or not. In the future it can be extended to only return success if container modeling is also extended in a way the it keeps track of trivial insertions and deletions. Differential Revision: https://reviews.llvm.org/D70818
2019-11-20 16:15:42 +08:00
// CHECK-NEXT: alpha.cplusplus.STLAlgorithmModeling:AggressiveStdFindModeling = false
[analyzer][DirectIvarAssignment] Turn DirectIvarAssignmentForAnnotatedFunctions into a checker option Since this is an alpha checker, I don't worry about backward compatibility :) Differential Revision: https://reviews.llvm.org/D78121
2020-04-14 23:13:41 +08:00
// CHECK-NEXT: alpha.osx.cocoa.DirectIvarAssignment:AnnotatedFunctions = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtExec = 0x04
// CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtRead = 0x01
[analyzer] Add yaml parser to GenericTaintChecker While we implemented taint propagation rules for several builtin/standard functions, there's a natural desire for users to add such rules to custom functions. A series of patches will implement an option that allows users to annotate their functions with taint propagation rules through a YAML file. This one adds parsing of the configuration file, which may be specified in the commands line with the analyzer config: alpha.security.taint.TaintPropagation:Config. The configuration may contain propagation rules, filter functions (remove taint) and sink functions (give a warning if it gets a tainted value). I also added a new header for future checkers to conveniently read YAML files as checker options. Differential Revision: https://reviews.llvm.org/D59555 llvm-svn: 367190
2019-07-28 21:38:04 +08:00
// CHECK-NEXT: alpha.security.taint.TaintPropagation:Config = ""
[analyzer] StdLibraryFunctionsChecker: Add option to display loaded summaries Reviewers: NoQ, Szelethus, baloghadamsoftware, balazske Subscribers: whisperity, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, gamesh411, Charusso, steakhal, ASDenysPetrov, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D78118
2020-04-14 23:40:42 +08:00
// CHECK-NEXT: apiModeling.StdCLibraryFunctions:DisplayLoadedSummaries = false
[analyzer][StdLibraryFunctionsChecker] Add POSIX file handling functions Adding file handling functions from the POSIX standard (2017). A new checker option is introduced to enable them. In follow-up patches I am going to upstream networking, pthread, and other groups of POSIX functions. Differential Revision: https://reviews.llvm.org/D82288
2020-06-22 17:00:02 +08:00
// CHECK-NEXT: apiModeling.StdCLibraryFunctions:ModelPOSIX = false
[analyzer] FixItHint: Apply and test hints with the Clang-Tidy's script Summary: This patch introduces a way to apply the fix-its by the Analyzer: `-analyzer-config apply-fixits=true`. The fix-its should be testable, therefore I have copied the well-tested `check_clang_tidy.py` script. The idea is that the Analyzer's workflow is different so it would be very difficult to use only one script for both Tidy and the Analyzer, the script would diverge a lot. Example test: `// RUN: %check-analyzer-fixit %s %t -analyzer-checker=core` When the copy-paste happened the original authors were: @alexfh, @zinovy.nis, @JonasToth, @hokein, @gribozavr, @lebedev.ri Reviewed By: NoQ, alexfh, zinovy.nis Differential Revision: https://reviews.llvm.org/D69746
2020-03-04 13:24:52 +08:00
// CHECK-NEXT: apply-fixits = false
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: avoid-suppressing-null-argument-paths = false
// CHECK-NEXT: c++-allocator-inlining = true
// CHECK-NEXT: c++-container-inlining = false
// CHECK-NEXT: c++-inlining = destructors
// CHECK-NEXT: c++-shared_ptr-inlining = false
// CHECK-NEXT: c++-stdlib-inlining = true
// CHECK-NEXT: c++-temp-dtor-inlining = true
// CHECK-NEXT: c++-template-inlining = true
Add static analyzer support for conditionally executing static initializers. llvm-svn: 178318
2013-03-29 08:09:28 +08:00
// CHECK-NEXT: cfg-conditional-static-initializers = true
[CFG] Add an option to expand CXXDefaultInitExpr into aggregate initialization This is useful for clients that are relying on linearized CFGs for evaluating subexpressions and want the default initializer to be evaluated properly. The upcoming lifetime analysis is using this but it might also be useful for the static analyzer at some point. Differential Revision: https://reviews.llvm.org/D71642
2019-12-18 09:53:26 +08:00
// CHECK-NEXT: cfg-expand-default-aggr-inits = false
CFG: Add CFGElement for automatic variables that leave the scope Summary: This mimics the implementation for the implicit destructors. The generation of this scope leaving elements is hidden behind a flag to the CFGBuilder, thus it should not affect existing code. Currently, I'm missing a test (it's implicitly tested by the clang-tidy lifetime checker that I'm proposing). I though about a test using debug.DumpCFG, but then I would have to add an option to StaticAnalyzer/Core/AnalyzerOptions to enable the scope leaving CFGElement, which would only be useful to that particular test. Any other ideas how I could make a test for this feature? Reviewers: krememek, jordan_rose Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15031 llvm-svn: 307759
2017-07-12 15:04:19 +08:00
// CHECK-NEXT: cfg-implicit-dtors = true
// CHECK-NEXT: cfg-lifetime = false
[CFG] Add LoopExit information to CFG This patch introduces a new CFG element CFGLoopExit that indicate when a loop ends. It does not deal with returnStmts yet (left it as a TODO). It hidden behind a new analyzer-config flag called cfg-loopexit (false by default). Test cases added. The main purpose of this patch right know is to make loop unrolling and loop widening easier and more efficient. However, this information can be useful for future improvements in the StaticAnalyzer core too. Differential Revision: https://reviews.llvm.org/D35668 llvm-svn: 311235
2017-08-19 19:19:16 +08:00
// CHECK-NEXT: cfg-loopexit = false
[CFG] Add extra context to C++ constructor statement elements. This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
2018-02-09 06:58:15 +08:00
// CHECK-NEXT: cfg-rich-constructors = true
[analyzer] Add scope information to CFG This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate when a local scope begins and ends respectively. We use first VarDecl declared in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements into corresponding basic blocks. Differential Revision: https://reviews.llvm.org/D16403 llvm-svn: 327258
2018-03-12 20:26:15 +08:00
// CHECK-NEXT: cfg-scopes = false
[analyzer] Enable cfg-temporary-dtors by default. Don't enable c++-temp-dtor-inlining by default yet, due to this reference counting pointe problem. Otherwise the new mode seems stable and allows us to incrementally fix C++ problems in much less hacky ways. Differential Revision: https://reviews.llvm.org/D43804 llvm-svn: 326461
2018-03-02 02:53:13 +08:00
// CHECK-NEXT: cfg-temporary-dtors = true
[analyzer][CallAndMessage] Add checker options for each bug type iAs listed in the summary D77846, we have 5 different categories of bugs we're checking for in CallAndMessage. I think the documentation placed in the code explains my thought process behind my decisions quite well. A non-obvious change I had here is removing the entry for CallAndMessageUnInitRefArg. In fact, I removed the CheckerNameRef typed field back in D77845 (it was dead code), so that checker didn't really exist in any meaningful way anyways. Differential Revision: https://reviews.llvm.org/D77866
2020-04-06 01:53:22 +08:00
// CHECK-NEXT: core.CallAndMessage:ArgInitializedness = true
// CHECK-NEXT: core.CallAndMessage:ArgPointeeInitializedness = false
// CHECK-NEXT: core.CallAndMessage:CXXDeallocationArg = true
// CHECK-NEXT: core.CallAndMessage:CXXThisMethodCall = true
// CHECK-NEXT: core.CallAndMessage:FunctionPointer = true
// CHECK-NEXT: core.CallAndMessage:NilReceiver = true
// CHECK-NEXT: core.CallAndMessage:ParameterCount = true
// CHECK-NEXT: core.CallAndMessage:UndefReceiver = true
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: cplusplus.Move:WarnOn = KnownsAndLocals
[analyzer] Warning for default constructed unique_ptr dereference Summary: Add support for warning incase of default constructed unique pointer dereferences Reviewed By: NoQ, Szelethus, vsavchenko, xazax.hun Tags: #clang Differential Revision: https://reviews.llvm.org/D81315
2020-06-26 08:31:20 +08:00
// CHECK-NEXT: cplusplus.SmartPtrModeling:ModelSmartPtrDereference = false
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: crosscheck-with-z3 = false
// CHECK-NEXT: ctu-dir = ""
[analyzer] Add CTUImportCppThreshold for C++ files Summary: The default CTUImportThreshold (8) seems to be too conservative with C projects. We increase this value to 24 and we introduce another threshold for C++ source files (defaulted to 8) because their AST is way more compilcated than C source files. Differential Revision: https://reviews.llvm.org/D83475
2020-07-09 20:26:23 +08:00
// CHECK-NEXT: ctu-import-cpp-threshold = 8
// CHECK-NEXT: ctu-import-threshold = 24
[analyzer][CrossTU][NFC] Generalize to external definitions instead of external functions Summary: This is just changing naming and documentation to be general about external definitions that can be imported for cross translation unit analysis. There is at least a plan to add VarDecls: D46421 Reviewers: NoQ, xazax.hun, martong, a.sidorin, george.karpenkov, serge-sans-paille Reviewed By: xazax.hun, martong Subscribers: mgorny, whisperity, baloghadamsoftware, szepet, rnkovacs, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D56441 llvm-svn: 350852
2019-01-11 01:44:04 +08:00
// CHECK-NEXT: ctu-index-name = externalDefMap.txt
[analyzer] On-demand parsing capability for CTU Summary: Introduce on-demand parsing of needed ASTs during CTU analysis. The index-file format is extended, and analyzer-option CTUInvocationList is added to specify the exact invocations needed to parse the needed source-files. Reviewers: martong, balazske, Szelethus, xazax.hun, whisperity Reviewed By: martong, xazax.hun Subscribers: gribozavr2, thakis, ASDenysPetrov, ormris, mgorny, whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75665
2020-06-10 14:59:04 +08:00
// CHECK-NEXT: ctu-invocation-list = invocations.yaml
[analyzer] Add minimal support for fix-it hints. Allow attaching fixit hints to Static Analyzer BugReports. Fixits are attached either to the bug report itself or to its notes (path-sensitive event notes or path-insensitive extra notes). Add support for fixits in text output (including the default text output that goes without notes, as long as the fixit "belongs" to the warning). Add support for fixits in the plist output mode. Implement a fixit for the path-insensitive DeadStores checker. Only dead initialization warning is currently covered. Implement a fixit for the path-sensitive VirtualCall checker when the virtual method is not pure virtual (in this case the "fix" is to suppress the warning by qualifying the call). Both fixits are under an off-by-default flag for now, because they require more careful testing. Differential Revision: https://reviews.llvm.org/D65182 llvm-svn: 371257
2019-09-07 04:55:29 +08:00
// CHECK-NEXT: deadcode.DeadStores:ShowFixIts = false
[analyzer] Add a checker option to detect nested dead stores Enables the users to specify an optional flag which would warn for more dead stores. Previously it ignored if the dead store happened e.g. in an if condition. if ((X = generate())) { // dead store to X } This patch introduces the `WarnForDeadNestedAssignments` option to the checker, which is `false` by default - so this change would not affect any previous users. I have updated the code, tests and the docs as well. If I missed something, tell me. I also ran the analysis on Clang which generated 14 more reports compared to the unmodified version. All of them seemed reasonable for me. Related previous patches: rGf224820b45c6847b91071da8d7ade59f373b96f3 Reviewers: NoQ, krememek, Szelethus, baloghadamsoftware Reviewed By: Szelethus Patch by Balázs Benics! Differential Revision: https://reviews.llvm.org/D66733 llvm-svn: 370767
2019-09-03 23:22:43 +08:00
// CHECK-NEXT: deadcode.DeadStores:WarnForDeadNestedAssignments = true
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:* = false
// CHECK-NEXT: debug.AnalysisOrder:Bind = false
[analyzer][AnalysisOrderChecker] Display the CallEvent type in preCall/postCall Exactly what it says on the tin! The included testfile demonstrates why this is important -- for C++ dynamic memory operators, we don't always recognize custom, or even standard-specified new/delete operators as CXXAllocatorCall or CXXDeallocatorCall. Differential Revision: https://reviews.llvm.org/D77391
2020-03-02 00:49:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:EndAnalysis = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:EndFunction = false
[analyzer] Enable constructor support in evalCall event. Pass EvalCallOptions via runCheckersForEvalCall into defaultEvalCall. Update the AnalysisOrderChecker to support evalCall for testing. Differential Revision: https://reviews.llvm.org/D82256
2020-06-25 09:30:41 +08:00
// CHECK-NEXT: debug.AnalysisOrder:EvalCall = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:LiveSymbols = false
// CHECK-NEXT: debug.AnalysisOrder:NewAllocator = false
[analyzer] Escape symbols conjured into specific regions during a conservative EvalCall This patch introduced additional PointerEscape callbacks after conservative calls for output parameters. This should not really affect the current checkers but the upcoming FuchsiaHandleChecker relies on this heavily. Differential Revision: https://reviews.llvm.org/D71224
2019-12-10 08:26:38 +08:00
// CHECK-NEXT: debug.AnalysisOrder:PointerEscape = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:PostCall = false
// CHECK-NEXT: debug.AnalysisOrder:PostStmtArraySubscriptExpr = false
[analyzer][AnalysisOrderChecker] Display the CallEvent type in preCall/postCall Exactly what it says on the tin! The included testfile demonstrates why this is important -- for C++ dynamic memory operators, we don't always recognize custom, or even standard-specified new/delete operators as CXXAllocatorCall or CXXDeallocatorCall. Differential Revision: https://reviews.llvm.org/D77391
2020-03-02 00:49:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:PostStmtCXXConstructExpr = false
// CHECK-NEXT: debug.AnalysisOrder:PostStmtCXXDeleteExpr = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:PostStmtCXXNewExpr = false
// CHECK-NEXT: debug.AnalysisOrder:PostStmtCastExpr = false
// CHECK-NEXT: debug.AnalysisOrder:PostStmtOffsetOfExpr = false
// CHECK-NEXT: debug.AnalysisOrder:PreCall = false
// CHECK-NEXT: debug.AnalysisOrder:PreStmtArraySubscriptExpr = false
[analyzer][AnalysisOrderChecker] Display the CallEvent type in preCall/postCall Exactly what it says on the tin! The included testfile demonstrates why this is important -- for C++ dynamic memory operators, we don't always recognize custom, or even standard-specified new/delete operators as CXXAllocatorCall or CXXDeallocatorCall. Differential Revision: https://reviews.llvm.org/D77391
2020-03-02 00:49:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:PreStmtCXXConstructExpr = false
// CHECK-NEXT: debug.AnalysisOrder:PreStmtCXXDeleteExpr = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: debug.AnalysisOrder:PreStmtCXXNewExpr = false
// CHECK-NEXT: debug.AnalysisOrder:PreStmtCastExpr = false
// CHECK-NEXT: debug.AnalysisOrder:PreStmtOffsetOfExpr = false
// CHECK-NEXT: debug.AnalysisOrder:RegionChanges = false
[analyzer] Display the checker name in the text output Exactly what it says on the tin! There is no reason I think not to have this. Also, I added test files for checkers that emit warning under the wrong name. Differential Revision: https://reviews.llvm.org/D76605
2020-03-20 23:45:53 +08:00
// CHECK-NEXT: display-checker-name = true
[CTU] Add DisplayCTUProgress analyzer switch Summary: With a new switch we may be able to print to stderr if a new TU is being loaded during CTU. This is very important for higher level scripts (like CodeChecker) to be able to parse this output so they can create e.g. a zip file in case of a Clang crash which contains all the related TU files. Reviewers: xazax.hun, Szelethus, a_sidorin, george.karpenkov Subscribers: whisperity, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Differential Revision: https://reviews.llvm.org/D55135 llvm-svn: 348594
2018-12-07 22:56:02 +08:00
// CHECK-NEXT: display-ctu-progress = false
[analyzer] Move analyzer-eagerly-assume to AnalyzerOptions, enable by default Differential Revision: https://reviews.llvm.org/D51251 llvm-svn: 340963
2018-08-30 04:29:17 +08:00
// CHECK-NEXT: eagerly-assume = true
[CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision. Before C++17 copy elision was optional, even if the elidable copy/move constructor had arbitrary side effects. The elidable constructor is present in the AST, but marked as elidable. In these cases CFG now contains additional information that allows its clients to figure out if a temporary object is only being constructed so that to pass it to an elidable constructor. If so, it includes a reference to the elidable constructor's construction context, so that the client could elide the elidable constructor and construct the object directly at its final destination. Differential Revision: https://reviews.llvm.org/D47616 llvm-svn: 335795
2018-06-28 08:04:54 +08:00
// CHECK-NEXT: elide-constructors = true
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: expand-macros = false
// CHECK-NEXT: experimental-enable-naive-ctu-analysis = false
[analyzer] Switch the default exploration strategy to priority queue based on coverage After the investigation it seems safe to flip the switch. Differential Revision: https://reviews.llvm.org/D43782 llvm-svn: 326157
2018-02-27 09:31:56 +08:00
// CHECK-NEXT: exploration_strategy = unexplored_first_queue
Have AnalyzerOptions::getBooleanOption() stick the matching config string in the config table so that it can be dumped as part of the config dumper. Add a test to show that these options are sticking and can be cross-checked using FileCheck. llvm-svn: 164954
2012-10-02 02:28:19 +08:00
// CHECK-NEXT: faux-bodies = true
[analyzer] Replace -analyzer-no-eagerly-trim-egraph with graph-trim-interval. After every 1000 CFGElements processed, the ExplodedGraph trims out nodes that satisfy a number of criteria for being "boring" (single predecessor, single successor, and more). Rather than controlling this with a cc1 option, which can only disable this behavior, we now have an analyzer-config option, 'graph-trim-interval', which can change this interval from 1000 to something else. Setting the value to 0 disables reclamation. The next commit relies on this behavior to actually test anything. llvm-svn: 166528
2012-10-24 07:59:05 +08:00
// CHECK-NEXT: graph-trim-interval = 1000
[analyzer] Add -analyzer-config option for function size the inliner considers as large Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function size the inliner considers as large, in relation to "max-times-inline-large". The option defaults to the original hard coded behaviour, which I believe should be adjustable with the other inlining settings. The analyzer-config test has been modified so that the analyzer will reach the getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it is dumped by the debug checker. A patch by Sean Eveson! Differential Revision: http://reviews.llvm.org/D12406 llvm-svn: 247463
2015-09-12 04:14:05 +08:00
// CHECK-NEXT: inline-lambdas = true
[analyzer] Replace "-analyzer-ipa" with "-analyzer-config ipa". The idea is to eventually place all analyzer options under "analyzer-config". In addition, this lays the ground for introduction of a high-level analyzer mode option, which will influence the default setting for IPAMode. llvm-svn: 173385
2013-01-25 07:15:30 +08:00
// CHECK-NEXT: ipa = dynamic-bifurcate
Tweak AnalyzerOptions::getOptionAsInteger() to populate the string table, making it printable with the ConfigDump checker. Along the way, fix a really serious bug where the value was getting parsed from the string in code that was in an assert() call. This means in a Release-Asserts build this code wouldn't work as expected. llvm-svn: 165041
2012-10-03 04:31:56 +08:00
// CHECK-NEXT: ipa-always-inline-size = 3
[analyzer] Bump a few default performance thresholds. This makes the analyzer around 10% slower by default, allowing it to find deeper bugs. Default values for the following -analyzer-config change: max-nodes: 150000 -> 225000; max-inlinable-size: 50 -> 100. rdar://problem/32539666 Differential Revision: https://reviews.llvm.org/D34277 llvm-svn: 305900
2017-06-21 19:29:35 +08:00
// CHECK-NEXT: max-inlinable-size = 100
// CHECK-NEXT: max-nodes = 225000
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: max-symbol-complexity = 35
[analyzer] Implement "do not inline large functions many times" performance heuristic After inlining a function with more than 13 basic blocks 32 times, we are not going to inline it anymore. The idea is that inlining large functions leads to drastic performance implications. Since the function has already been inlined, we know that we've analyzed it in many contexts. The following metrics are used: - Large function is a function with more than 13 basic blocks (we should switch to another metric, like cyclomatic complexity) - We consider that we've inlined a function many times if it's been inlined 32 times. This number is configurable with -analyzer-config max-times-inline-large=xx This heuristic addresses a performance regression introduced with inlining on one benchmark. The analyzer on this benchmark became 60 times slower with inlining turned on. The heuristic allows us to analyze it in 24% of the time. The performance improvements on the other benchmarks I've tested with are much lower - under 10%, which is expected. llvm-svn: 170361
2012-12-18 04:08:51 +08:00
// CHECK-NEXT: max-times-inline-large = 32
[analyzer] Add -analyzer-config option for function size the inliner considers as large Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function size the inliner considers as large, in relation to "max-times-inline-large". The option defaults to the original hard coded behaviour, which I believe should be adjustable with the other inlining settings. The analyzer-config test has been modified so that the analyzer will reach the getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it is dumped by the debug checker. A patch by Sean Eveson! Differential Revision: http://reviews.llvm.org/D12406 llvm-svn: 247463
2015-09-12 04:14:05 +08:00
// CHECK-NEXT: min-cfg-size-treat-functions-as-large = 14
[analyzer] Add "-analyzer-config mode=[deep|shallow] ". The idea is to introduce a higher level "user mode" option for different use scenarios. For example, if one wants to run the analyzer for a small project each time the code is built, they would use the "shallow" mode. The user mode option will influence the default settings for the lower-level analyzer options. For now, this just influences the ipa modes, but we plan to find more optimal settings for them. llvm-svn: 173386
2013-01-25 07:15:34 +08:00
// CHECK-NEXT: mode = deep
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: model-path = ""
// CHECK-NEXT: notes-as-events = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: nullability:NoDiagnoseCallsToSystemHeaders = false
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: objc-inlining = true
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: optin.cplusplus.UninitializedObject:CheckPointeeInitialization = false
// CHECK-NEXT: optin.cplusplus.UninitializedObject:IgnoreGuardedFields = false
// CHECK-NEXT: optin.cplusplus.UninitializedObject:IgnoreRecordsWithField = ""
// CHECK-NEXT: optin.cplusplus.UninitializedObject:NotesAsWarnings = false
// CHECK-NEXT: optin.cplusplus.UninitializedObject:Pedantic = false
// CHECK-NEXT: optin.cplusplus.VirtualCall:PureOnly = false
[analyzer] Add minimal support for fix-it hints. Allow attaching fixit hints to Static Analyzer BugReports. Fixits are attached either to the bug report itself or to its notes (path-sensitive event notes or path-insensitive extra notes). Add support for fixits in text output (including the default text output that goes without notes, as long as the fixit "belongs" to the warning). Add support for fixits in the plist output mode. Implement a fixit for the path-insensitive DeadStores checker. Only dead initialization warning is currently covered. Implement a fixit for the path-sensitive VirtualCall checker when the virtual method is not pure virtual (in this case the "fix" is to suppress the warning by qualifying the call). Both fixits are under an off-by-default flag for now, because they require more careful testing. Differential Revision: https://reviews.llvm.org/D65182 llvm-svn: 371257
2019-09-07 04:55:29 +08:00
// CHECK-NEXT: optin.cplusplus.VirtualCall:ShowFixIts = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: optin.osx.cocoa.localizability.NonLocalizedStringChecker:AggressiveReport = false
// CHECK-NEXT: optin.performance.Padding:AllowedPad = 24
// CHECK-NEXT: osx.NumberObjectConversion:Pedantic = false
// CHECK-NEXT: osx.cocoa.RetainCount:TrackNSCFStartParam = false
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: prune-paths = true
[analyzer] "Force" LazyCompoundVals on bind when they are simple enough. The analyzer uses LazyCompoundVals to represent rvalues of aggregate types, most importantly structs and arrays. This allows us to efficiently copy around an entire struct, rather than doing a memberwise load every time a struct rvalue is encountered. This can also keep memory usage down by allowing several structs to "share" the same snapshotted bindings. However, /lookup/ through LazyCompoundVals can be expensive, especially since they can end up chaining back to the original value. While we try to reuse LazyCompoundVals whenever it's safe, and cache information about this transitivity, the fact is it's sometimes just not a good idea to perpetuate LazyCompoundVals -- the tradeoffs just aren't worth it. This commit changes RegionStore so that binding a LazyCompoundVal to struct will do a memberwise copy if the struct is simple enough. Today's definition of "simple enough" is "up to N scalar members" (see below), but that could easily be changed in the future. This is enough to bring the test case in PR15697 back down to a manageable analysis time (within 20% of its original time, in an unfair test where the new analyzer is not compiled with LTO). The actual value of "N" is controlled by a new -analyzer-config option, 'region-store-small-struct-limit'. It defaults to "2", meaning structs with zero, one, or two scalar members will be considered "simple enough" for this code path. It's worth noting that a more straightforward implementation would do this on load, not on bind, and make use of the structure we already have for this: CompoundVal. A long time ago, this was actually how RegionStore modeled aggregate-to-aggregate copies, but today it's only used for compound literals. Unfortunately, it seems that we've special-cased LazyCompoundVal in certain places (such as liveness checks) but failed to similarly special-case CompoundVal in all of them. Until we're confident that CompoundVal is handled properly everywhere, this solution is safer, since the entire optimization is just an implementation detail of RegionStore. <rdar://problem/13599304> llvm-svn: 179767
2013-04-19 00:33:46 +08:00
// CHECK-NEXT: region-store-small-struct-limit = 2
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: report-in-main-source-file = false
[analyzer] Serialize statistics to plist when serialize-stats=true is set Differential Revision: https://reviews.llvm.org/D43131 llvm-svn: 324793
2018-02-10 09:49:20 +08:00
// CHECK-NEXT: serialize-stats = false
[analyzer] Analysis: Silence checkers Summary: This patch introduces a new `analyzer-config` configuration: `-analyzer-config silence-checkers` which could be used to silence the given checkers. It accepts a semicolon separated list, packed into quotation marks, e.g: `-analyzer-config silence-checkers="core.DivideZero;core.NullDereference"` It could be used to "disable" core checkers, so they model the analysis as before, just if some of them are too noisy it prevents to emit reports. This patch also adds support for that new option to the scan-build. Passing the option `-disable-checker core.DivideZero` to the scan-build will be transferred to `-analyzer-config silence-checkers=core.DivideZero`. Reviewed By: NoQ, Szelethus Differential Revision: https://reviews.llvm.org/D66042 llvm-svn: 369078
2019-08-16 09:53:14 +08:00
// CHECK-NEXT: silence-checkers = ""
[analyzer] Evaluate all non-checker config options before analysis In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
2018-12-01 04:44:00 +08:00
// CHECK-NEXT: stable-report-filename = false
// CHECK-NEXT: suppress-c++-stdlib = true
// CHECK-NEXT: suppress-inlined-defensive-checks = true
// CHECK-NEXT: suppress-null-return-paths = true
[analyzer] Enable control dependency condition tracking by default This patch concludes my GSoC'19 project by enabling track-conditions by default. Differential Revision: https://reviews.llvm.org/D66381 llvm-svn: 369616
2019-08-22 11:08:48 +08:00
// CHECK-NEXT: track-conditions = true
[analyzer] Add a debug analyzer config to place an event for each tracked condition Differential Revision: https://reviews.llvm.org/D63642 llvm-svn: 365208
2019-07-05 22:00:08 +08:00
// CHECK-NEXT: track-conditions-debug = false
[analyzer] Insert checker options into AnalyzerOption::ConfigTable The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
2019-05-17 17:29:44 +08:00
// CHECK-NEXT: unix.DynamicMemoryModeling:Optimistic = false
[StaticAnalyzer] Completely unrolling specific loops with known bound option This feature allows the analyzer to consider loops to completely unroll. New requirements/rules (for unrolling) can be added easily via ASTMatchers. Right now it is hidden behind a flag, the aim is to find the correct heuristic and create a solution which results higher coverage % and more precise analysis, thus can be enabled by default. Right now the blocks which belong to an unrolled loop are marked by the LoopVisitor which adds them to the ProgramState. Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is marked then we skip its investigating. That means, it won't be considered to be visited more than the maximal bound for visiting since it won't be checked. llvm-svn: 309006
2017-07-26 03:23:23 +08:00
// CHECK-NEXT: unroll-loops = false
Reapply r251621 "[Analyzer] Widening loops which do not exit" It was not the cause of the build bot failure. llvm-svn: 251702
2015-10-30 23:23:57 +08:00
// CHECK-NEXT: widen-loops = false