summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/UninitializedObject
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.Artem Dergachev2019-09-091-2/+2
| | | | | | | | | | | | | 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
* [analyzer] Fix analyzer warnings on analyzer.Artem Dergachev2019-08-281-4/+5
| | | | | | | | | 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
* [analyzer] CastValueChecker: Rewrite dead header hotfixCsaba Dabis2019-08-222-2/+2
| | | | llvm-svn: 369607
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-2/+2
| | | | | | | | | | 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
* [analyzer] Remove the default value arg from getChecker*OptionKristof Umann2019-05-171-8/+5
| | | | | | | | | | | | | | | | | | | 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
* [analyzer][UninitializedObjectChecker] PR41741: Regard all scalar types as ↵Kristof Umann2019-05-051-2/+1
| | | | | | | | | | | | | | | | | | | | primitive. https://bugs.llvm.org/show_bug.cgi?id=41741 Pretty much the same as D61246 and D61106, this time for __complex__ types. Upon further investigation, I realized that we should regard all types Type::isScalarType returns true for as primitive, so I merged isMemberPointerType(), isBlockPointerType() and isAnyComplexType()` into that instead. I also stumbled across yet another bug, https://bugs.llvm.org/show_bug.cgi?id=41753, but it seems to be unrelated to this checker. Differential Revision: https://reviews.llvm.org/D61569 llvm-svn: 359998
* [analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitiveKristof Umann2019-04-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugs.llvm.org/show_bug.cgi?id=41611 Similarly to D61106, the checker ran over an llvm_unreachable for vector types: struct VectorSizeLong { VectorSizeLong() {} __attribute__((__vector_size__(16))) long x; }; void __vector_size__LongTest() { VectorSizeLong v; } Since, according to my short research, "The vector_size attribute is only applicable to integral and float scalars, although arrays, pointers, and function return values are allowed in conjunction with this construct." [src: https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Vector-Extensions.html#Vector-Extensions] vector types are safe to regard as primitive. Differential Revision: https://reviews.llvm.org/D61246 llvm-svn: 359539
* [analyzer][UninitializedObjectChecker] PR41590: Regard _Atomic types as ↵Kristof Umann2019-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | primitive https://bugs.llvm.org/show_bug.cgi?id=41590 For the following code snippet, UninitializedObjectChecker crashed: struct MyAtomicInt { _Atomic(int) x; MyAtomicInt() {} }; void entry() { MyAtomicInt b; } The problem was that _Atomic types were not regular records, unions, dereferencable or primitive, making the checker hit the llvm_unreachable at lib/StaticAnalyzer/Checkers/UninitializedObject/UninitializedObjectChecker.cpp:347. The solution is to regard these types as primitive as well. The test case shows that with this addition, not only are we able to get rid of the crash, but we can identify x as uninitialized. Differential Revision: https://reviews.llvm.org/D61106 llvm-svn: 359230
* [analyzer] Move UninitializedObjectChecker out of alphaKristof Umann2019-04-191-5/+5
| | | | | | | | | Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the 'optin.cplusplus' package. Differential Revision: https://reviews.llvm.org/D58573 llvm-svn: 358797
* [analyzer] Emit an error rather than assert on invalid checker option inputKristof Umann2019-03-081-1/+8
| | | | | | | | | | | Asserting on invalid input isn't very nice, hence the patch to emit an error instead. This is the first of many patches to overhaul the way we handle checker options. Differential Revision: https://reviews.llvm.org/D57850 llvm-svn: 355704
* [analyzer] Enable subcheckers to possess checker optionsKristof Umann2019-03-041-9/+8
| | | | | | | | | | | | | | | | 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
* [analyzer][UninitializedObjectChecker] New flag to ignore guarded ↵Kristof Umann2019-02-022-13/+110
| | | | | | | | | | | | | | | | | | | uninitialized fields This patch is an implementation of the ideas discussed on the mailing list[1]. The idea is to somewhat heuristically guess whether the field that was confirmed to be uninitialized is actually guarded with ifs, asserts, switch/cases and so on. Since this is a syntactic check, it is very much prone to drastically reduce the amount of reports the checker emits. The reports however that do not get filtered out though have greater likelihood of them manifesting into actual runtime errors. [1] http://lists.llvm.org/pipermail/cfe-dev/2018-September/059255.html Differential Revision: https://reviews.llvm.org/D51866 llvm-svn: 352959
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-261-0/+4
| | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-193-12/+9
| | | | | | | | | | | | | | | | | 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
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-152-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 &registry); 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
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-103-5/+5
| | | | | | | | | | | | | | 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
* [analyzer][UninitializedObjectChecker] Uninit regions are only reported onceKristof Umann2018-11-183-18/+64
| | | | | | | | | | 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] Restrict AnalyzerOptions' interface so that non-checker objects ↵Kristof Umann2018-11-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | have to be registered One of the reasons why AnalyzerOptions is so chaotic is that options can be retrieved from the command line whenever and wherever. This allowed for some options to be forgotten for a looooooong time. Have you ever heard of "region-store-small-struct-limit"? In order to prevent this in the future, I'm proposing to restrict AnalyzerOptions' interface so that only checker options can be retrieved without special getters. I would like to make every option be accessible only through a getter, but checkers from plugins are a thing, so I'll have to figure something out for that. This also forces developers who'd like to add a new option to register it properly in the .def file. This is done by * making the third checker pointer parameter non-optional, and checked by an assert to be non-null. * I added new, but private non-checkers option initializers, meant only for internal use, * Renamed these methods accordingly (mind the consistent name for once with getBooleanOption!): - getOptionAsString -> getCheckerStringOption, - getOptionAsInteger -> getCheckerIntegerOption * The 3 functions meant for initializing data members (with the not very descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names) were renamed to be overloads of the getAndInitOption function name. * All options were in some way retrieved via getCheckerOption. I removed it, and moved the logic to getStringOption and getCheckerStringOption. This did cause some code duplication, but that's the only way I could do it, now that checker and non-checker options are separated. Note that the non-checker version inserts the new option to the ConfigTable with the default value, but the checker version only attempts to find already existing entries. This is how it always worked, but this is clunky and I might end reworking that too, so we can eventually get a ConfigTable that contains the entire configuration of the analyzer. Differential Revision: https://reviews.llvm.org/D53483 llvm-svn: 346113
* [analyzer][UninitializedObjectChecker] No longer using nonloc::LazyCompoundValKristof Umann2018-10-211-25/+26
| | | | | | | | As rightly pointed out by @NoQ, nonloc::LazyCompoundVals were only used to acquire a constructed object's region, which isn't what LazyCompoundVal was made for. Differential Revision: https://reviews.llvm.org/D51300 llvm-svn: 344879
* Revert "[Lex] TokenConcatenation now takes const Preprocessor"Eric Liu2018-10-111-3/+3
| | | | | | This reverts commit r344262. This was an unintentional commit. llvm-svn: 344267
* [Lex] TokenConcatenation now takes const PreprocessorEric Liu2018-10-111-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D52502 llvm-svn: 344262
* [analyzer][UninitializedObjectChecker] Reports Loc fields pointing to themselvesKristof Umann2018-10-111-19/+49
| | | | | | | | | | | I've added a new functionality, the checker is now able to detect and report fields pointing to themselves. I figured this would fit well into the checker as there's no reason for a pointer to point to itself instead of being nullptr. Differential Revision: https://reviews.llvm.org/D51305 llvm-svn: 344242
* Revert untintentionally commited changesEric Liu2018-10-021-3/+3
| | | | llvm-svn: 343574
* [Lex] TokenConcatenation now takes const PreprocessorEric Liu2018-10-021-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D52502 llvm-svn: 343573
* Revert untintentionally commited changesKristof Umann2018-09-271-3/+3
| | | | llvm-svn: 343205
* [Lex] TokenConcatenation now takes const PreprocessorKristof Umann2018-09-271-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D52502 llvm-svn: 343204
* [analyzer][UninitializedObjectChecker] Using the new const methods of ↵Kristof Umann2018-09-232-20/+10
| | | | | | | | ImmutableList Differential Revision: https://reviews.llvm.org/D51886 llvm-svn: 342834
* [analyzer] Restore final on NeedsCastLocField. NFCIlya Biryukov2018-09-141-1/+1
| | | | | | To fix compiler warning about non-virtual dtor introduced in r342221. llvm-svn: 342225
* [analyzer][UninitializedObjectChecker] Support for nonloc::LocAsIntegerKristof Umann2018-09-142-14/+23
| | | | | | Differential Revision: https://reviews.llvm.org/D49437 llvm-svn: 342221
* [analyzer][UninitializedObjectChecker] New flag to ignore records based on ↵Kristof Umann2018-09-142-5/+39
| | | | | | | | | | | | | | | | | it's fields Based on a suggestion from @george.karpenkov. In some cases, structs are used as unions with a help of a tag/kind field. This patch adds a new string flag (a pattern), that is matched against the fields of a record, and should a match be found, the entire record is ignored. For more info refer to http://lists.llvm.org/pipermail/cfe-dev/2018-August/058906.html and to the responses to that, especially http://lists.llvm.org/pipermail/cfe-dev/2018-August/059215.html. Differential Revision: https://reviews.llvm.org/D51680 llvm-svn: 342220
* [analyzer][UninitializedObjectChecker] Refactored checker optionsKristof Umann2018-09-143-59/+63
| | | | | | | | | | | | | Since I plan to add a number of new flags, it made sense to encapsulate them in a new struct, in order not to pollute FindUninitializedFields's constructor with new boolean options with super long names. This revision practically reverts D50508, since FindUninitializedFields now accesses the pedantic flag anyways. Differential Revision: https://reviews.llvm.org/D51679 llvm-svn: 342219
* [analyzer][UninitializedObjectChecker] Correct dynamic type is acquired for ↵Kristof Umann2018-09-141-0/+8
| | | | | | | | record pointees Differential Revision: https://reviews.llvm.org/D50892 llvm-svn: 342217
* [analyzer][UninitializedObjectChecker] Updated commentsKristof Umann2018-09-143-74/+67
| | | | | | | | | | | | | Some of the comments are incorrect, imprecise, or simply nonexistent. Since I have a better grasp on how the analyzer works, it makes sense to update most of them in a single swoop. I tried not to flood the code with comments too much, this amount feels just right to me. Differential Revision: https://reviews.llvm.org/D51417 llvm-svn: 342215
* [analyzer][UninitializedObjectChecker] Fixed dereferencingKristof Umann2018-09-143-77/+86
| | | | | | | | | | iThis patch aims to fix derefencing, which has been debated for months now. Instead of working with SVals, the function now relies on TypedValueRegion. Differential Revision: https://reviews.llvm.org/D51057 llvm-svn: 342213
* fix comment typoNico Weber2018-08-271-1/+1
| | | | llvm-svn: 340743
* [analyzer] Correctly marked a virtual function 'override'Kristof Umann2018-08-211-1/+1
| | | | llvm-svn: 340280
* [analyzer][UninitializedObjectChecker] Explicit namespace resolution for ↵Kristof Umann2018-08-212-7/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | inherited data members For the following example: struct Base { int x; }; // In a different translation unit struct Derived : public Base { Derived() {} }; For a call to Derived::Derived(), we'll receive a note that this->x is uninitialized. Since x is not a direct field of Derived, it could be a little confusing. This patch aims to fix this, as well as the case when the derived object has a field that has the name as an inherited uninitialized data member: struct Base { int x; // note: uninitialized field 'this->Base::x' }; struct Derived : public Base { int x = 5; Derived() {} }; Differential Revision: https://reviews.llvm.org/D50905 llvm-svn: 340272
* [analyzer][UninitializedObjectChecker] Added documentation to the checker listKristof Umann2018-08-211-12/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D50904 llvm-svn: 340266
* [analyzer][UninitializedObjectChecker] Refactoring p6.: Move dereferencing ↵Kristof Umann2018-08-212-56/+63
| | | | | | | | | | | | to a function Now that it has it's own file, it makes little sense for isPointerOrReferenceUninit to be this large, so I moved dereferencing to a separate function. Differential Revision: https://reviews.llvm.org/D50509 llvm-svn: 340265
* [NFC] Don't define static function in header (UninitializedObject.h)Andrei Elovikov2018-08-202-5/+3
| | | | | | | | | | | | | | | | Summary: See also http://lists.llvm.org/pipermail/cfe-users/2016-January/000854.html for the reasons why it's bad. Reviewers: Szelethus, erichkeane Reviewed By: Szelethus Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50963 llvm-svn: 340174
* [analyzer] Made a buildbot happy.Kristof Umann2018-08-141-2/+4
| | | | llvm-svn: 339655
* [analyzer][UninitializedObjectChecker] Void pointers are casted back to ↵Kristof Umann2018-08-141-2/+40
| | | | | | | | their dynamic type in note message Differential Revision: https://reviews.llvm.org/D49228 llvm-svn: 339653
* [analyzer] Fix UninitializedObjectChecker to not crash on uninitialized "id" ↵George Karpenkov2018-08-132-2/+2
| | | | | | | | fields Differential Revision: https://reviews.llvm.org/D50673 llvm-svn: 339631
* Fix Clang warnings and bad #include filenames in r339595 and r339599.Richard Smith2018-08-133-5/+7
| | | | llvm-svn: 339624
* [analyzer][UninitializedObjectChecker] Refactoring p5.: Handle pedantic mode ↵Kristof Umann2018-08-132-14/+19
| | | | | | | | in the checker class only Differential Revision: https://reviews.llvm.org/D50508 llvm-svn: 339601
* [analyzer][UninitializedObjectChecker] Refactoring p4.: Wrap FieldRegions ↵Kristof Umann2018-08-133-113/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and reduce weight on FieldChainInfo Before this patch, FieldChainInfo used a spaghetti: it took care of way too many cases, even though it was always meant as a lightweight wrapper around ImmutableList<const FieldRegion *>. This problem is solved by introducing a lightweight polymorphic wrapper around const FieldRegion *, FieldNode. It is an interface that abstracts away special cases like pointers/references, objects that need to be casted to another type for a proper note messages. Changes to FieldChainInfo: * Now wraps ImmutableList<const FieldNode &>. * Any pointer/reference related fields and methods were removed * Got a new add method. This replaces it's former constructors as a way to create a new FieldChainInfo objects with a new element. Changes to FindUninitializedField: * In order not to deal with dynamic memory management, when an uninitialized field is found, the note message for it is constructed and is stored instead of a FieldChainInfo object. (see doc around addFieldToUninits). Some of the test files are changed too, from now on uninitialized pointees of references always print "uninitialized pointee" instead of "uninitialized field" (which should've really been like this from the beginning). I also updated every comment according to these changes. Differential Revision: https://reviews.llvm.org/D50506 llvm-svn: 339599
* [analyzer][UninitializedObjectChecker] Refactoring p3.: printTail moved out ↵Kristof Umann2018-08-133-16/+17
| | | | | | | | | | from FieldChainInfo This is a standalone part of the effort to reduce FieldChainInfos inteerface. Differential Revision: https://reviews.llvm.org/D50505 llvm-svn: 339596
* [analyzer][UninitializedObjectChecker] Refactoring p2.: Moving pointer ↵Kristof Umann2018-08-133-0/+854
chasing to a separate file In this patch, the following classes and functions have been moved to a header file: FieldChainInfo FindUninitializedFields isPrimitiveType This also meant that they moved from anonymous namespace to clang::ento. Code related to pointer chasing now relies in its own file. There's absolutely no functional change in this patch -- its literally just copy pasting. Differential Revision: https://reviews.llvm.org/D50504 llvm-svn: 339595
OpenPOWER on IntegriCloud