#
2b3d49b6 |
| 14-Aug-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement o
[Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
show more ...
|
#
fc76d855 |
| 13-Aug-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it const
When I'm new to a file/codebase, I personally find C++'s strong static type system to be a great aid. BugReporter.c
[analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it const
When I'm new to a file/codebase, I personally find C++'s strong static type system to be a great aid. BugReporter.cpp is still painful to read however: function calls are made with mile long parameter lists, seemingly all of them taken with a non-const reference/pointer. This patch fixes nothing but this: make a few things const, and hammer it until it compiles.
Differential Revision: https://reviews.llvm.org/D65382
llvm-svn: 368735
show more ...
|
#
6d716ef1 |
| 13-Aug-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Refactoring BugReporter.cpp P3.: std::shared_pointer<PathDiagnosticPiece> -> PathDiagnosticPieceRef
find clang/ -type f -exec sed -i 's/std::shared_ptr<PathDiagnosticPiece>/PathDiagn
[analyzer][NFC] Refactoring BugReporter.cpp P3.: std::shared_pointer<PathDiagnosticPiece> -> PathDiagnosticPieceRef
find clang/ -type f -exec sed -i 's/std::shared_ptr<PathDiagnosticPiece>/PathDiagnosticPieceRef/g' {} \; git diff -U3 --no-color HEAD^ | clang-format-diff-6.0 -p1 -i
Just as C++ is meant to be refactored, right?
Differential Revision: https://reviews.llvm.org/D65381
llvm-svn: 368717
show more ...
|
Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init |
|
#
68983321 |
| 18-Jul-2019 |
Csaba Dabis <dabis.csaba98@gmail.com> |
[analyzer] MallocChecker: Prevent Integer Set Library false positives
Summary: Integer Set Library using retain-count based allocation which is not modeled in MallocChecker.
Reviewed By: NoQ
Tags:
[analyzer] MallocChecker: Prevent Integer Set Library false positives
Summary: Integer Set Library using retain-count based allocation which is not modeled in MallocChecker.
Reviewed By: NoQ
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64680
llvm-svn: 366391
show more ...
|
#
49a3ad21 |
| 16-Jul-2019 |
Rui Ueyama <ruiu@google.com> |
Fix parameter name comments using clang-tidy. NFC.
This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch:
$ git clone
Fix parameter name comments using clang-tidy. NFC.
This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch:
$ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}
llvm-svn: 366177
show more ...
|
Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4 |
|
#
12140142 |
| 01-Jul-2019 |
Nathan Huckleberry <nhuck@google.com> |
[analyzer] Support kfree in MallocChecker
Summary: kmalloc is freed with kfree in the linux kernel. kmalloc support was added in r204832, but kfree was not. Adding kfree fixes incorrectly detected m
[analyzer] Support kfree in MallocChecker
Summary: kmalloc is freed with kfree in the linux kernel. kmalloc support was added in r204832, but kfree was not. Adding kfree fixes incorrectly detected memory leaks.
Reviewers: NoQ, nickdesaulniers, dcoughlin, Szelethus
Reviewed By: NoQ, Szelethus
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64030
llvm-svn: 364875
show more ...
|
Revision tags: llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
#
83cc1b35 |
| 17-May-2019 |
Kristof Umann <kristof.umann@ericsson.com> |
[analyzer] Remove the default value arg from getChecker*Option
Since D57922, the config table contains every checker option, and it's default value, so having it as an argument for getChecker*Option
[analyzer] Remove the default value arg from getChecker*Option
Since D57922, the config table contains every checker option, and it's default value, so having it as an argument for getChecker*Option is redundant.
By the time any of the getChecker*Option function is called, we verified the value in CheckerRegistry (after D57860), so we can confidently assert here, as any irregularities detected at this point must be a programmer error. However, in compatibility mode, verification won't happen, so the default value must be restored.
This implies something else, other than adding removing one more potential point of failure -- debug.ConfigDumper will always contain valid values for checker/package options!
Differential Revision: https://reviews.llvm.org/D59195
llvm-svn: 361042
show more ...
|
Revision tags: llvmorg-8.0.1-rc1 |
|
#
b9fb121a |
| 06-May-2019 |
Richard Smith <richard-llvm@metafoo.co.uk> |
[c++20] Implement P1009R2: allow omitting the array bound in an array new expression.
This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language mode
[c++20] Implement P1009R2: allow omitting the array bound in an array new expression.
This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language modes (though it can never actually be used before C++11 mode).
llvm-svn: 360006
show more ...
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
#
088b1c9c |
| 04-Mar-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Enable subcheckers to possess checker options
Under the term "subchecker", I mean checkers that do not have a checker class on their own, like unix.MallocChecker to unix.DynamicMemoryMode
[analyzer] Enable subcheckers to possess checker options
Under the term "subchecker", I mean checkers that do not have a checker class on their own, like unix.MallocChecker to unix.DynamicMemoryModeling.
Since a checker object was required in order to retrieve checker options, subcheckers couldn't possess options on their own.
This patch is also an excuse to change the argument order of getChecker*Option, it always bothered me, now it resembles the actual command line argument (checkername:option=value).
Differential Revision: https://reviews.llvm.org/D57579
llvm-svn: 355297
show more ...
|
Revision tags: llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2 |
|
#
204bf2bb |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue. The solution i
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue. The solution is to assert when CheckerManager::getChecker is called on an unregistered checker, and assert when CheckerManager::registerChecker is called on a checker that is already registered.
Differential Revision: https://reviews.llvm.org/D55429
llvm-svn: 352292
show more ...
|
#
8fd74ebf |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep wi
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep within the implementation. For example, many checkers (like RetainCount, Malloc or CString) modelled a certain functionality, and exposed certain reportable bug types to the user. For example, while MallocChecker models many many different types of memory handling, the actual "unix.MallocChecker" checker the user was exposed to was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming issue almost impossible. (The checker naming issue being that if a checker registered more than one checker within its registry function, both checker object recieved the same name) Also, if the user explicitly disabled a checker that was a dependency of another that _was_ explicitly enabled, it implicitly, without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their dependencies within the TableGen file Checkers.td, and exposes the same functionality to plugins and statically linked non-generated checkers through CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies, makes sure that checkers are added to CheckerManager in the correct order, and makes sure that if a dependency is disabled, so will be every checker that depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies, which is a list of Checkers. * Move unix checkers before cplusplus, as there is no forward declaration in tblgen :/ * Add the following new checkers: - StackAddrEscapeBase - StackAddrEscapeBase - CStringModeling - DynamicMemoryModeling (base of the MallocChecker family) - IteratorModeling (base of the IteratorChecker family) - ValistBase - SecuritySyntaxChecker (base of bcmp, bcopy, etc...) - NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker) - IvarInvalidationModeling (base of IvarInvalidation checker family) - RetainCountBase (base of RetainCount and OSObjectRetainCount) * Clear up and registry functions in MallocChecker, happily remove old FIXMEs. * Add a new addDependency function to CheckerRegistry. * Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
show more ...
|
#
058a7a45 |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. T
[analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways.
A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed.
This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953
Differential Revision: https://reviews.llvm.org/D55424
llvm-svn: 352277
show more ...
|
Revision tags: llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
#
2c2d0b6e |
| 18-Jan-2019 |
George Karpenkov <ekarpenkov@apple.com> |
Revert "Fix failing MSan bots"
This reverts commit 2cedaaef383d8d6142046074ffebc2bb5a914778.
Revert with a fix.
llvm-svn: 351575
|
#
d5dd6a5f |
| 18-Jan-2019 |
Vlad Tsyrklevich <vlad@tsyrklevich.net> |
Fix failing MSan bots
Revert r351508-351514, this block of changes introduced a consistent MSan failure on the sanitizer bots.
llvm-svn: 351528
|
#
1aa2bf8e |
| 18-Jan-2019 |
George Karpenkov <ekarpenkov@apple.com> |
[analyzer] Extend BugType constructor to accept "SuppressOnSink" as a parameter
Differential Revision: https://reviews.llvm.org/D56884
llvm-svn: 351510
|
#
9af1d2d1 |
| 17-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
Revert rC349281 '[analyzer][MallocChecker][NFC] Document and reorganize some functions'
Accidentally commited earlier with the same commit title, but really it should've been "Revert rC349283 '[anal
Revert rC349281 '[analyzer][MallocChecker][NFC] Document and reorganize some functions'
Accidentally commited earlier with the same commit title, but really it should've been "Revert rC349283 '[analyzer][MallocChecker] Improve warning messages on double-delete errors'"
llvm-svn: 349344
show more ...
|
#
09e86e77 |
| 17-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
Revert rC349281 '[analyzer][MallocChecker][NFC] Document and reorganize some functions'
llvm-svn: 349340
|
#
a0334666 |
| 17-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
Reverting bitfield size to attempt to fix a windows buildbot
llvm-svn: 349336
|
#
a82810c5 |
| 15-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer][MallocChecker] Improve warning messages on double-delete errors
Differential Revision: https://reviews.llvm.org/D54834
llvm-svn: 349283
|
#
cf6bb77f |
| 15-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer][MallocChecker][NFC] Document and reorganize some functions
This patch merely reorganizes some things, and features no functional change.
In detail:
* Provided documentation, or moved ex
[analyzer][MallocChecker][NFC] Document and reorganize some functions
This patch merely reorganizes some things, and features no functional change.
In detail:
* Provided documentation, or moved existing documentation in more obvious places. * Added dividers. (the //===----------===// thing). * Moved getAllocationFamily, printAllocDeallocName, printExpectedAllocName and printExpectedDeallocName in the global namespace on top of the file where AllocationFamily is declared, as they are very strongly related. * Moved isReleased and MallocUpdateRefState near RefState's definition for the same reason. * Realloc modeling was very poor in terms of variable and structure naming, as well as documentation, so I renamed some of them and added much needed docs. * Moved function IdentifierInfos to a separate struct, and moved isMemFunction, isCMemFunction adn isStandardNewDelete inside it. This makes the patch affect quite a lot of lines, should I extract it to a separate one? * Moved MallocBugVisitor out of MallocChecker. * Preferred switches to long else-if branches in some places. * Neatly organized some RUN: lines.
Differential Revision: https://reviews.llvm.org/D54823
llvm-svn: 349281
show more ...
|
#
76a21502 |
| 15-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend, whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can imagine, used to circumvent the problem that the registry functions of the checkers are located in the clangStaticAnalyzerCheckers library, but that library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend depends on both of those libraries.
One can make the observation however, that CheckerRegistry has no place in Core, it isn't used there at all! The only place where it is used is Frontend, which is where it ultimately belongs.
This move implies that since include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:
class CheckerRegistry;
void registerBuiltinCheckers(CheckerRegistry ®istry);
it had to re purposed, as CheckerRegistry is no longer available to clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h, which actually describes it a lot better -- it does not contain the registration functions for checkers, but only those generated by the tblgen files.
Differential Revision: https://reviews.llvm.org/D54436
llvm-svn: 349275
show more ...
|
#
b23ccecb |
| 10-Dec-2018 |
Raphael Isemann <teemperor@gmail.com> |
Misc typos fixes in ./lib folder
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`
Reviewers: teemperor
Reviewed By: teemperor
Subs
Misc typos fixes in ./lib folder
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D55475
llvm-svn: 348755
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
#
549f9cd4 |
| 30-Nov-2018 |
Kristof Umann <dkszelethus@gmail.com> |
[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
[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
show more ...
|
#
e2b5438a |
| 30-Nov-2018 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] MallocChecker: Avoid redundant transitions.
Don't generate a checker-tagged node unconditionally on the first checkDeadSymbols callback when no pointers are tracked.
This is a tiny perfo
[analyzer] MallocChecker: Avoid redundant transitions.
Don't generate a checker-tagged node unconditionally on the first checkDeadSymbols callback when no pointers are tracked.
This is a tiny performance optimization; it may change the behavior slightly by making Static Analyzer bail out on max-nodes one node later (which is good) but any test would either break for no good reason or become useless every time someone sneezes.
Differential Revision: https://reviews.llvm.org/D54013
llvm-svn: 347955
show more ...
|