#
72210ce7 |
| 24-May-2020 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
Fix Wdocumentation warnings after argument renaming. NFC.
|
#
1d393eac |
| 20-May-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer] Fix a null FunctionDecl dereference bug after D75432
|
#
392222dd |
| 25-Feb-2020 |
Kristóf Umann <dkszelethus@gmail.com> |
[analyzer][NFC][MallocChecker] Convert many parameters into CallEvent
Exactly what it says on the tin! This is clearly not the end of the road in this direction, the parameters could be merged far m
[analyzer][NFC][MallocChecker] Convert many parameters into CallEvent
Exactly what it says on the tin! This is clearly not the end of the road in this direction, the parameters could be merged far more with the use of CallEvent or a better value type in the CallDescriptionMap, but this was shockingly difficult enough on its own. I expect that simplifying the file further will be far easier moving forward.
The end goal is to research how we could create a more mature checker interaction infrastructure for more complicated C++ modeling, and I'm pretty sure that being able successfully split up our giants is the first step in this direction.
Differential Revision: https://reviews.llvm.org/D75432
show more ...
|
#
f2be30de |
| 01-Mar-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Merge checkNewAllocator's paramaters into CXXAllocatorCall
Party based on this thread: http://lists.llvm.org/pipermail/cfe-dev/2020-February/064754.html.
This patch merges two of CX
[analyzer][NFC] Merge checkNewAllocator's paramaters into CXXAllocatorCall
Party based on this thread: http://lists.llvm.org/pipermail/cfe-dev/2020-February/064754.html.
This patch merges two of CXXAllocatorCall's parameters, so that we are able to supply a CallEvent object to check::NewAllocatorCall (see the description of D75430 to see why this would be great).
One of the things mentioned by @NoQ was the following:
I think at this point we might actually do a good job sorting out this check::NewAllocator issue because we have a "separate" "Environment" to hold the other SVal, which is "objects under construction"! - so we should probably simply teach CXXAllocatorCall to extract the value from the objects-under-construction trait of the program state and we're good.
I had MallocChecker in my crosshair for now, so I admittedly threw together something as a proof of concept. Now that I know that this effort is worth pursuing though, I'll happily look for a solution better then demonstrated in this patch.
Differential Revision: https://reviews.llvm.org/D75431
show more ...
|
#
2e5e42d4 |
| 05-May-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][MallocChecker] When modeling realloc-like functions, don't early return if the argument is symbolic
The very essence of MallocChecker lies in 2 overload sets: the FreeMemAux functions and
[analyzer][MallocChecker] When modeling realloc-like functions, don't early return if the argument is symbolic
The very essence of MallocChecker lies in 2 overload sets: the FreeMemAux functions and the MallocMemAux functions. The former houses most of the error checking as well (aside from leaks), such as incorrect deallocation. There, we check whether the argument's MemSpaceRegion is the heap or unknown, and if it isn't, we know we encountered a bug (aside from a corner case patched by @balazske in D76830), as specified by MEM34-C.
In ReallocMemAux, which really is the combination of FreeMemAux and MallocMemAux, we incorrectly early returned if the memory argument of realloc is non-symbolic. The problem is, one of the cases where this happens when we know precisely what the region is, like an array, as demonstrated in the test file. So, lets get rid of this false negative :^)
Side note, I dislike the warning message and the associated checker name, but I'll address it in a later patch.
Differential Revision: https://reviews.llvm.org/D79415
show more ...
|
#
9d69072f |
| 01-Mar-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Introduce CXXDeallocatorCall, deploy it in MallocChecker
One of the pain points in simplifying MallocCheckers interface by gradually changing to CallEvent is that a variety of C++ al
[analyzer][NFC] Introduce CXXDeallocatorCall, deploy it in MallocChecker
One of the pain points in simplifying MallocCheckers interface by gradually changing to CallEvent is that a variety of C++ allocation and deallocation functionalities are modeled through preStmt<...> where CallEvent is unavailable, and a single one of these callbacks can prevent a mass parameter change.
This patch introduces a new CallEvent, CXXDeallocatorCall, which happens after preStmt<CXXDeleteExpr>, and can completely replace that callback as demonstrated.
Differential Revision: https://reviews.llvm.org/D75430
show more ...
|
#
703a1b8c |
| 26-Mar-2020 |
Louis Dionne <ldionne@apple.com> |
[analyzer][MallocChecker][NFC] Split checkPostCall up, deploy CallDescriptionMap
Since its important to know whether a function frees memory (even if its a reallocating function!), I used two CallDe
[analyzer][MallocChecker][NFC] Split checkPostCall up, deploy CallDescriptionMap
Since its important to know whether a function frees memory (even if its a reallocating function!), I used two CallDescriptionMaps to merge all CallDescriptions into it. MemFunctionInfoTy no longer makes sense, it may never have, but for now, it would be more of a distraction then anything else.
Differential Revision: https://reviews.llvm.org/D68165
show more ...
|
#
dcc04e09 |
| 30-Mar-2020 |
Balázs Kéri <1.int32@gmail.com> |
[Analyzer][MallocChecker] No warning for kfree of ZERO_SIZE_PTR.
Summary: The kernel kmalloc function may return a constant value ZERO_SIZE_PTR if a zero-sized block is allocated. This special value
[Analyzer][MallocChecker] No warning for kfree of ZERO_SIZE_PTR.
Summary: The kernel kmalloc function may return a constant value ZERO_SIZE_PTR if a zero-sized block is allocated. This special value is allowed to be passed to kfree and should produce no warning.
This is a simple version but should be no problem. The macro is always detected independent of if this is a kernel source code or any other code.
Reviewers: Szelethus, martong
Reviewed By: Szelethus, martong
Subscribers: rnkovacs, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76830
show more ...
|
#
bda3dd0d |
| 27-Mar-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions
Some checkers may not only depend on language options but also analyzer options. To make this possible this patc
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions
Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered.
Differential Revision: https://reviews.llvm.org/D75271
show more ...
|
#
30a8b770 |
| 27-Mar-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][MallocChecker] Fix that kfree only takes a single argument
Exactly what it says on the tin!
https://www.kernel.org/doc/htmldocs/kernel-api/API-kfree.html
Differential Revision: https://
[analyzer][MallocChecker] Fix that kfree only takes a single argument
Exactly what it says on the tin!
https://www.kernel.org/doc/htmldocs/kernel-api/API-kfree.html
Differential Revision: https://reviews.llvm.org/D76917
show more ...
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
#
e5513336 |
| 20-Sep-2019 |
Kristóf Umann <dkszelethus@gmail.com> |
[analyzer][MallocChecker][NFC] Change the use of IdentifierInfo* to CallDescription
Exactly what it says on the tin! I decided not to merge this with the patch that changes all these to a CallDescri
[analyzer][MallocChecker][NFC] Change the use of IdentifierInfo* to CallDescription
Exactly what it says on the tin! I decided not to merge this with the patch that changes all these to a CallDescriptionMap object, so the patch is that much more trivial.
Differential Revision: https://reviews.llvm.org/D68163
show more ...
|
#
9fd7ce7f |
| 26-Sep-2019 |
Kristóf Umann <dkszelethus@gmail.com> |
[analyzer][MallocChecker][NFC] Communicate the allocation family to auxiliary functions with parameters
The following series of refactoring patches aim to fix the horrible mess that MallocChecker.cp
[analyzer][MallocChecker][NFC] Communicate the allocation family to auxiliary functions with parameters
The following series of refactoring patches aim to fix the horrible mess that MallocChecker.cpp is.
I genuinely hate this file. It goes completely against how most of the checkers are implemented, its by far the biggest headache regarding checker dependencies, checker options, or anything you can imagine. On top of all that, its just bad code. Its seriously everything that you shouldn't do in C++, or any other language really. Bad variable/class names, in/out parameters... Apologies, rant over.
So: there are a variety of memory manipulating function this checker models. One aspect of these functions is their AllocationFamily, which we use to distinguish between allocation kinds, like using free() on an object allocated by operator new. However, since we always know which function we're actually modeling, in fact we know it compile time, there is no need to use tricks to retrieve this information out of thin air n+1 function calls down the line. This patch changes many methods of MallocChecker to take a non-optional AllocationFamily template parameter (which also makes stack dumps a bit nicer!), and removes some no longer needed auxiliary functions.
Differential Revision: https://reviews.llvm.org/D68162
show more ...
|
#
601687bf |
| 30-Jan-2020 |
Charusso <dabis.csaba98@gmail.com> |
[analyzer] DynamicSize: Remove 'getExtent()' from regions
Summary: This patch introduces a placeholder for representing the dynamic size of regions. It also moves the `getExtent()` method of `SubReg
[analyzer] DynamicSize: Remove 'getExtent()' from regions
Summary: This patch introduces a placeholder for representing the dynamic size of regions. It also moves the `getExtent()` method of `SubRegions` to the `MemRegionManager` as `getStaticSize()`.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D69540
show more ...
|
#
adcd0268 |
| 28-Jan-2020 |
Benjamin Kramer <benny.kra@googlemail.com> |
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly m
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
show more ...
|
#
bce1cce6 |
| 18-Dec-2019 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] Teach MismatchedDealloc about initWithBytesNoCopy with deallocator.
MallocChecker warns when memory is passed into -[NSData initWithBytesNoCopy] but isn't allocated by malloc(), because i
[analyzer] Teach MismatchedDealloc about initWithBytesNoCopy with deallocator.
MallocChecker warns when memory is passed into -[NSData initWithBytesNoCopy] but isn't allocated by malloc(), because it will be deallocated by free(). However, initWithBytesNoCopy has an overload that takes an arbitrary block for deallocating the object. If such overload is used, it is no longer necessary to make sure that the memory is allocated by malloc().
show more ...
|
#
2f960472 |
| 03-Dec-2019 |
Tyker <tyker1@outlook.com> |
[NFCI] update formating for misleading indentation warning
Reviewers: xbolva00
Reviewed By: xbolva00
Differential Revision: https://reviews.llvm.org/D70861
|
#
1b38002c |
| 22-Sep-2019 |
Benjamin Kramer <benny.kra@googlemail.com> |
Move classes into anonymous namespaces. NFC.
llvm-svn: 372495
|
#
c90fda6a |
| 21-Sep-2019 |
Kristof Umann <kristof.umann@ericsson.com> |
Attempt to fix a windows buildbot failure
llvm-svn: 372462
|
#
96be6f48 |
| 20-Sep-2019 |
Kristof Umann <kristof.umann@ericsson.com> |
Fix a documentation error
llvm-svn: 372419
|
#
951cd32f |
| 20-Sep-2019 |
Kristof Umann <kristof.umann@ericsson.com> |
Reland '[analyzer][MallocChecker][NFC] Document and reorganize some functions'
Differential Revision: https://reviews.llvm.org/D54823
llvm-svn: 372414
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5 |
|
#
72649423 |
| 12-Sep-2019 |
Kristof Umann <kristof.umann@ericsson.com> |
[analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, a
[analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks.
This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks.
Differential Revision: https://reviews.llvm.org/D67140
llvm-svn: 371760
show more ...
|
#
6b85f8e9 |
| 11-Sep-2019 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.
These static functions deal with ExplodedNodes which is something we don't want the PathDiagnostic interface to know anyth
[analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.
These static functions deal with ExplodedNodes which is something we don't want the PathDiagnostic interface to know anything about, as it's planned to be moved out of libStaticAnalyzerCore.
Differential Revision: https://reviews.llvm.org/D67382
llvm-svn: 371659
show more ...
|
#
8535b8ec |
| 11-Sep-2019 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] NFC: Re-implement stack hints as a side map in BugReport.
That's one of the few random entities in the PathDiagnostic interface that are specific to the Static Analyzer. By moving them ou
[analyzer] NFC: Re-implement stack hints as a side map in BugReport.
That's one of the few random entities in the PathDiagnostic interface that are specific to the Static Analyzer. By moving them out we could let everybody use path diagnostics without linking against Static Analyzer.
Differential Revision: https://reviews.llvm.org/D67381
llvm-svn: 371658
show more ...
|
Revision tags: llvmorg-9.0.0-rc4 |
|
#
2f169e7c |
| 09-Sep-2019 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.
Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by cons
[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.
Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type.
This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes.
Differential Revision: https://reviews.llvm.org/D66572
llvm-svn: 371450
show more ...
|
Revision tags: llvmorg-9.0.0-rc3 |
|
#
630f7daf |
| 28-Aug-2019 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] Fix analyzer warnings on analyzer.
Write tests for the actual crash that was found. Write comments and refactor code around 17 style bugs and suppress 3 false positives.
Differential Rev
[analyzer] Fix analyzer warnings on analyzer.
Write tests for the actual crash that was found. Write comments and refactor code around 17 style bugs and suppress 3 false positives.
Differential Revision: https://reviews.llvm.org/D66847
llvm-svn: 370246
show more ...
|