summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Switch retain count checker for OSObject to use OS_* attributesGeorge Karpenkov2018-11-301-3/+3
| | | | | | | | Instead of generalized reference counting annotations. Differential Revision: https://reviews.llvm.org/D55041 llvm-svn: 347948
* [analyzer] [NFC] Minor refactoring of RetainCountDiagnosticsGeorge Karpenkov2018-11-301-7/+11
| | | | | | | | | Move visitors to the implementation file, move a complicated logic into a function. Differential Revision: https://reviews.llvm.org/D55036 llvm-svn: 347946
* [analyzer] For OSObject, trust that functions starting with GetGeorge Karpenkov2018-11-301-0/+11
| | | | | | | | (uppercase) are also getters. Differential Revision: https://reviews.llvm.org/D55035 llvm-svn: 347945
* [analyzer] Print a fully qualified name for functions in RetainCountChecker ↵George Karpenkov2018-11-301-9/+14
| | | | | | | | | | | diagnostics Attempt to get a fully qualified name from AST if an SVal corresponding to the object is not available. Differential Revision: https://reviews.llvm.org/D55034 llvm-svn: 347944
* [analyzer] Add the type of the leaked object to the diagnostic messageGeorge Karpenkov2018-11-306-19/+23
| | | | | | | | | | | | If the object is a temporary, and there is no variable it binds to, let's at least print out the object name in order to help differentiate it from other temporaries. rdar://45175098 Differential Revision: https://reviews.llvm.org/D55033 llvm-svn: 347943
* [analyzer] Reference leaked object by name, even if it was created in an ↵George Karpenkov2018-11-303-6/+26
| | | | | | | | | | inlined function. rdar://45532181 Differential Revision: https://reviews.llvm.org/D54973 llvm-svn: 347942
* [analyzer] [NFC] Test dumping trimmed graphGeorge Karpenkov2018-11-301-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D54972 llvm-svn: 347941
* [analyzer][PlistMacroExpansion] Part 4.: Support for __VA_ARGS__Kristof Umann2018-11-292-84/+263
| | | | | | Differential Revision: https://reviews.llvm.org/D52986 llvm-svn: 347888
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-3/+3
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* [analyzer][PlistMacroExpansion] Part 3.: Macro arguments are expandedKristof Umann2018-11-272-88/+3913
| | | | | | | | This part focuses on expanding macro arguments. Differential Revision: https://reviews.llvm.org/D52795 llvm-svn: 347629
* [analyzer] INT50-CPP. Do not cast to an out-of-range enumeration checkerKristof Umann2018-11-241-0/+192
| | | | | | | | | | | | | | | This checker implements a solution to the "INT50-CPP. Do not cast to an out-of-range enumeration value" rule [1]. It lands in alpha for now, and a number of followup patches are planned in order to enable it by default. [1] https://www.securecoding.cert.org/confluence/display/cplusplus/INT50-CPP.+Do+not+cast+to+an+out-of-range+enumeration+value Patch by: Endre Fülöp and Alexander Zaitsev! Differential Revision: https://reviews.llvm.org/D33672 llvm-svn: 347513
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-3/+3
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-3/+3
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-3/+3
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-3/+3
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-3/+3
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* [analyzer][UninitializedObjectChecker] Uninit regions are only reported onceKristof Umann2018-11-181-0/+41
| | | | | | | | | | Especially with pointees, a lot of meaningless reports came from uninitialized regions that were already reported. This is fixed by storing all reported fields to the GDM. Differential Revision: https://reviews.llvm.org/D51531 llvm-svn: 347153
* [analyzer] ConversionChecker: handle floating pointKristof Umann2018-11-161-1/+30
| | | | | | | | | | | | | | | | | Extend the alpha.core.Conversion checker to handle implicit converions where a too large integer value is converted to a floating point type. Each floating point type has a range where it can exactly represent all integers; we emit a warning when the integer value is above this range. Although it is possible to exactly represent some integers which are outside of this range (those that are divisible by a large enough power of 2); we still report cast involving those, because their usage may lead to bugs. (For example, if 1<<24 is stored in a float variable x, then x==x+1 holds.) Patch by: Donát Nagy! Differential Revision: https://reviews.llvm.org/D52730 llvm-svn: 347006
* Reland '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name ↵Kristof Umann2018-11-052-9/+1150
| | | | | | and primitive expansion' llvm-svn: 346111
* Revert '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name ↵Kristof Umann2018-11-042-1150/+9
| | | | | | and primitive expansion' llvm-svn: 346096
* [analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and ↵Kristof Umann2018-11-042-9/+1150
| | | | | | | | | | | primitive expansion This patch adds a couple new functions to acquire the macro's name, and also expands it, although it doesn't expand the arguments, as seen from the test files Differential Revision: https://reviews.llvm.org/D52794 llvm-svn: 346095
* Fix test on Windows.Douglas Yung2018-11-031-1/+2
| | | | | | | | This test checks the entire output of a help option, the problem is that on Windows, the line break occurs in a different place causing the CHECK to fail because it is not expecting a line break. llvm-svn: 346070
* Revert r345562: "PR23833, DR2140: an lvalue-to-rvalue conversion on a ↵Richard Smith2018-11-031-2/+10
| | | | | | | | | | | | glvalue of type" This exposes a (known) CodeGen bug: it can't cope with emitting lvalue expressions that denote non-odr-used but usable-in-constant-expression variables. See PR39528 for a testcase. Reverted for now until that issue can be fixed. llvm-svn: 346065
* Remove the duplicated definition of size_tKristof Umann2018-11-021-1/+0
| | | | | | So hopefully windows won't complain. llvm-svn: 345997
* [analyzer] Fix diagnostics/explicit-suppression.cppFangrui Song2018-11-021-1/+1
| | | | | | *OI++ = *II++ is on line 670, not 668 llvm-svn: 345992
* [analyzer] Put llvm.Conventions back in alphaKristof Umann2018-11-025-39/+274
| | | | | | | | | | | | Interestingly, this many year old (when I last looked I remember 2010ish) checker was committed without any tests, so I thought I'd implement them, but I was shocked to see how I barely managed to get it working. The code is severely outdated, I'm not even sure it has ever been used, so I'd propose to move it back into alpha, and possibly even remove it. Differential Revision: https://reviews.llvm.org/D53856 llvm-svn: 345990
* [analyzer] New flag to print all -analyzer-config optionsKristof Umann2018-11-021-0/+33
| | | | | | | | A new -cc1 flag is avaible for the said purpose: -analyzer-config-help Differential Revision: https://reviews.llvm.org/D53296 llvm-svn: 345989
* [analyzer][NFC] Fix some incorrect uses of -analyzer-config optionsKristof Umann2018-11-024-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | I'm in the process of refactoring AnalyzerOptions. The main motivation behind here is to emit warnings if an invalid -analyzer-config option is given from the command line, and be able to list them all. In this patch, I found some flags that should've been used as checker options, or have absolutely no mention of in AnalyzerOptions, or are nonexistent. - NonLocalizedStringChecker now uses its "AggressiveReport" flag as a checker option - lib/StaticAnalyzer/Frontend/ModelInjector.cpp now accesses the "model-path" option through a getter in AnalyzerOptions - -analyzer-config path-diagnostics-alternate=false is not a thing, I removed it, - lib/StaticAnalyzer/Checkers/AllocationDiagnostics.cpp and lib/StaticAnalyzer/Checkers/AllocationDiagnostics.h are weird, they actually only contain an option getter. I deleted them, and fixed RetainCountChecker to get it's "leak-diagnostics-reference-allocation" option as a checker option, - "region-store-small-struct-limit" has a proper getter now. Differential Revision: https://reviews.llvm.org/D53276 llvm-svn: 345985
* Output "rule" information in SARIF exports.Aaron Ballman2018-11-015-2/+348
| | | | | | SARIF allows you to export descriptions about rules that are present in the SARIF log. Expose the help text table generated into Checkers.inc as the rule's "full description" and export all of the rules present in the analysis output. This information is useful for analysis result viewers like CodeSonar. llvm-svn: 345874
* Update to the 10-10 SARIF spec.Aaron Ballman2018-11-012-8/+6
| | | | | | This removes the Step property (which can be calculated by consumers trivially), and updates the schema and version numbers accordingly. llvm-svn: 345823
* [analyzer] SARIF: Suppress version testing in a more downstream-friendly manner.Artem Dergachev2018-11-012-2/+2
| | | | | | No functional change intended. llvm-svn: 345807
* [analyzer] pr39348: MallocChecker: Realize that sized delete isn't custom ↵Artem Dergachev2018-11-012-24/+46
| | | | | | | | | | | | | | | | | | | | | | | | | delete. MallocChecker no longer thinks that operator delete() that accepts the size of the object to delete (available since C++14 or under -fsized-deallocation) is some weird user-defined operator. Instead, it handles it like normal delete. Additionally, it exposes a regression in NewDelete-intersections.mm's testStandardPlacementNewAfterDelete() test, where the diagnostic is delayed from before the call of placement new into the code of placement new in the header. This happens because the check for pass-into-function-after-free for placement arguments is located in checkNewAllocator(), which happens after the allocator is inlined, which is too late. Move this use-after-free check into checkPreCall instead, where it works automagically because the guard that prevents it from working is useless and can be removed as well. This commit causes regressions under -analyzer-config c++-allocator-inlining=false but this option is essentially unsupported because the respective feature has been enabled by default quite a while ago. Differential Revision: https://reviews.llvm.org/D53543 llvm-svn: 345802
* [analyzer] Re-add custom OSIterator rule for RetainCountCheckerGeorge Karpenkov2018-10-311-0/+10
| | | | | | | | Turns out the rule is quite ubiquitous. Revert of https://reviews.llvm.org/D53628 llvm-svn: 345747
* [analyzer] RetainCountChecker: for now, do not trust the summaries of ↵George Karpenkov2018-10-311-23/+39
| | | | | | | | | | | | | | | | inlined code Trusting summaries of inlined code would require a more thorough work, as the current approach was causing too many false positives, as the new example in test. The culprit lies in the fact that we currently escape all variables written into a field (but not passed off to unknown functions!), which can result in inconsistent behavior. rdar://45655344 Differential Revision: https://reviews.llvm.org/D53902 llvm-svn: 345746
* [analyzer] Enable retain count checking for OSObject by defaGeorge Karpenkov2018-10-311-1/+1
| | | | | | | | The FP rate seems to be good enough now. Differential Revision: https://reviews.llvm.org/D53849 llvm-svn: 345745
* [analyzer][PlistMacroExpansion] Part 1.: New expand-macros flagKristof Umann2018-10-312-0/+395
| | | | | | | | | | | | | This is the first part of the implementation of the inclusion of macro expansions into the plist output. It adds a new flag that adds a new "macro_expansions" entry to each report that has PathDiagnosticPieces that were expanded from a macro. While there's an entry for each macro expansion, both the name of the macro and what it expands to is missing, and will be implemented in followup patches. Differential Revision: https://reviews.llvm.org/D52742 llvm-svn: 345724
* Changing the command line parameters sent to diff for this test.Aaron Ballman2018-10-302-2/+2
| | | | | | On some systems, -U 1 was being interpreted as -U -1. Trying -U1 to see if that's the universally accepted approach instead. llvm-svn: 345649
* Speculatively attempt to fix a failing testbot.Aaron Ballman2018-10-302-2/+2
| | | | | | A testbot ( http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/54690/) was failing with a complaint about an obsolete option that wasn't present in the command line in the first place. This replaces my guess at the "obsolete option" with a different spelling that will hopefully be more acceptable to this bot without breaking other bots. llvm-svn: 345635
* Add the ability to output static analysis results to SARIF.Aaron Ballman2018-10-302-0/+114
| | | | | | This allows users to specify SARIF (https://github.com/oasis-tcs/sarif-spec) as the output from the clang static analyzer so that the results can be read in by other tools, such as extensions to Visual Studio and VSCode, as well as static analyzers like CodeSonar. llvm-svn: 345628
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2018-10-301-10/+2
| | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. llvm-svn: 345562
* [analyzer] Allow padding checker to traverse simple class hierarchiesAlexander Shaposhnikov2018-10-301-0/+28
| | | | | | | | | | | | | | | The existing padding checker skips classes that have any base classes. This patch allows the checker to traverse very simple cases: classes that have no fields and have exactly one base class. This is important mostly in the case of array declarations. Patch by Max Bernstein! Test plan: make check-all Differential revision: https://reviews.llvm.org/D53206 llvm-svn: 345558
* [analyzer] [RetainCountChecker] Do not invalidate references passed to ↵George Karpenkov2018-10-251-0/+7
| | | | | | | | constructors and operators Differential Revision: https://reviews.llvm.org/D53660 llvm-svn: 345340
* [analyzer] Correct modelling of OSDynamicCast: eagerly state splitGeorge Karpenkov2018-10-251-1/+26
| | | | | | | | | | | | | | | | | | | | | Previously, OSDynamicCast was modeled as an identity. This is not correct: the output of OSDynamicCast may be zero even if the input was not zero (if the class is not of desired type), and thus the modeling led to false positives. Instead, we are doing eager state split: in one branch, the returned value is identical to the input parameter, and in the other branch, the returned value is zero. This patch required a substantial refactoring of canEval infrastructure, as now it can return different function summaries, and not just true/false. rdar://45497400 Differential Revision: https://reviews.llvm.org/D53624 llvm-svn: 345338
* [analyzer] Do not stop tracking CXX methods touching OSObject.George Karpenkov2018-10-231-5/+44
| | | | | | | | Trust generalized annotations for OSObject. Differential Revision: https://reviews.llvm.org/D53550 llvm-svn: 345100
* [analyzer] Trust summaries for OSObject::retain and OSObject::releaseGeorge Karpenkov2018-10-231-1/+1
| | | | | | | | Refactor the way in which summaries are consumed for safeMetaCast Differential Revision: https://reviews.llvm.org/D53549 llvm-svn: 345099
* [analyzer] Fix dumping for SymbolConjured conjured at no particular statement.Artem Dergachev2018-10-221-0/+15
| | | | llvm-svn: 344944
* [AST, analyzer] Transform rvalue cast outputs to lvalues ↵Aleksei Sidorin2018-10-202-2/+32
| | | | | | | | | | | | | (fheinous-gnu-extensions) Despite the fact that cast expressions return rvalues, GCC still handles such outputs as lvalues when compiling inline assembler. In this commit, we are treating it by removing LValueToRValue casts inside GCCAsmStmt outputs. Differential Revision: https://reviews.llvm.org/D45416 llvm-svn: 344864
* [analyzer] Teach CallEvent about C++17 aligned operator new().Artem Dergachev2018-10-151-0/+14
| | | | | | | | | | | | | | | | | | | | In C++17, when class C has large alignment value, a special case of overload resolution rule kicks in for expression new C that causes the aligned version of operator new() to be called. The aligned new has two arguments: size and alignment. However, the new-expression has only one "argument": the construct-expression for C(). This causes a false positive in core.CallAndMessage's check for matching number of arguments and number of parameters. Update CXXAllocatorCall, which is a CallEvent sub-class for operator new calls within new-expressions, so that the number of arguments always matched the number of parameters. rdar://problem/44738501 Differential Revision: https://reviews.llvm.org/D52957 llvm-svn: 344539
* [Analyzer] Iterator Checker - Part 10: Tests for iterators passed as parameterAdam Balogh2018-10-132-0/+35
| | | | | | | | | | In earlier Clang Static Analyzer versions `check::Bind() was not invoked for parameter passing, so we needed a trick which is not needed anymore. However add the tests to ensure its working. Differential Revision: https::/reviews.llvm.org/D32906 llvm-svn: 344443
OpenPOWER on IntegriCloud