summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [OpenMP] Fix data sharing analysis in nested clauseJoel E. Denny2018-12-191-7/+3
| | | | | | | | | | | | | | | | | | | | | | Without this patch, clang doesn't complain that X needs explicit data sharing attributes in the following: ``` #pragma omp target teams default(none) { #pragma omp parallel num_threads(X) ; } ``` However, clang does produce that complaint after the braces are removed. With this patch, clang complains in both cases. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D55861 llvm-svn: 349635
* [X86][SSE] Auto upgrade PADDUS/PSUBUS intrinsics to UADD_SAT/USUB_SAT ↵Simon Pilgrim2018-12-191-25/+8
| | | | | | | | | | generic intrinsics (clang) Sibling patch to D55855, this emits UADD_SAT/USUB_SAT generic intrinsics for the SSE saturated math intrinsics instead of expanding to a IR code sequence that could be difficult to reassemble. Differential Revision: https://reviews.llvm.org/D55879 llvm-svn: 349631
* [Index] Index paremeters in lambda expressions.Haojian Wu2018-12-191-0/+11
| | | | | | | | | | | | Summary: This fixes clangd couldn't find references for lambda parameters. Reviewers: ilya-biryukov Subscribers: ioeric, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D55437 llvm-svn: 349626
* Use "EvaluateAsRValue" instead of as a known int, because if it's not a knownBill Wendling2018-12-191-6/+6
| | | | | | integer we want to emit a diagnostic instead of asserting. llvm-svn: 349604
* Revert accidentally included code.Bill Wendling2018-12-191-8/+8
| | | | llvm-svn: 349603
* [Driver] Also obey -nostdlib++ when rewriting -lstdc++.Dan Albert2018-12-181-1/+3
| | | | | | | | | | | | Reviewers: pirama Reviewed By: pirama Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55856 llvm-svn: 349570
* Emit ASM input in a constant contextBill Wendling2018-12-183-10/+15
| | | | | | | | | | | | | | | | | Summary: Some ASM input constraints (e.g., "i" and "n") require immediate values. At O0, very few code transformations are performed. So if we cannot resolve to an immediate when emitting the ASM input we shouldn't delay its processing. Reviewers: rsmith, efriedma Reviewed By: efriedma Subscribers: rehana, efriedma, craig.topper, jyknight, cfe-commits Differential Revision: https://reviews.llvm.org/D55616 llvm-svn: 349561
* [OPENMP] parsing and sema support for 'close' map-type-modifierKelvin Li2018-12-188-138/+199
| | | | | | | | | | | | A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
* [CodeGen] Handle mixed-width ops in mixed-sign mul-with-overflow loweringVedant Kumar2018-12-181-5/+14
| | | | | | | | | | | | | | | | | | | | | | The special lowering for __builtin_mul_overflow introduced in r320902 fixed an ICE seen when passing mixed-sign operands to the builtin. This patch extends the special lowering to cover mixed-width, mixed-sign operands. In a few common scenarios, calls to muloti4 will no longer be emitted. This should address the latest comments in PR34920 and work around the link failure seen in: https://bugzilla.redhat.com/show_bug.cgi?id=1657544 Testing: - check-clang - A/B output comparison with: https://gist.github.com/vedantk/3eb9c88f82e5c32f2e590555b4af5081 Differential Revision: https://reviews.llvm.org/D55843 llvm-svn: 349542
* [OPENMP][NVPTX]Emit shared memory buffer for reduction as 128 bytesAlexey Bataev2018-12-181-0/+16
| | | | | | | | | | | buffer. Seems to me, nvlink has a bug with the proper support of the weakly linked symbols. It does not allow to define several shared memory buffer with the different sizes even with the weak linkage. Instead we always use 128 bytes buffer to prevent nvlink from the error message emission. llvm-svn: 349540
* Generate objc intrinsics instead of runtime calls as the ARC optimizer now ↵Pete Cooper2018-12-182-75/+94
| | | | | | | | | works only on intrinsics Differential Revision: https://reviews.llvm.org/D55802 Reviewers: rjmccall llvm-svn: 349535
* [OPENMP][NVPTX]Added extra sync point to the inter-warp copy function.Alexey Bataev2018-12-181-0/+5
| | | | | | | The parallel reduction operation requires an extra synchronization point in the inter-warp copy function to avoid divergence. llvm-svn: 349525
* [Driver][PS4] Do not implicitly link against asan or ubsan if -nostdlib or ↵Pierre Gousseau2018-12-182-3/+6
| | | | | | | | | | | | -nodefaultlibs on PS4. NFC for targets other than PS4. Respect -nostdlib and -nodefaultlibs when enabling asan or ubsan. Differential Revision: https://reviews.llvm.org/D55712 llvm-svn: 349508
* [NFC] Fix usage of Builder.insert(new Bitcast...)in CodeGenFunctionErich Keane2018-12-181-1/+1
| | | | | | | | | | | | This is exactly a "CreateBitCast", so refactor this to get rid of a 'new'. Note that this slightly changes the test, as the Builder is now seemingly smart enough to fold one of the bitcasts into the annotation call. Change-Id: I1733fb1fdf91f5c9d88651067130b9a4e7b5ab67 llvm-svn: 349506
* Emit -Wformat properly for bit-field promotions.Aaron Ballman2018-12-181-4/+28
| | | | | | | | Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C. Patch by Bevin Hansson. llvm-svn: 349497
* [PowerPC] Make no-PIC default to match GCC - CLANGStefan Pintilie2018-12-181-1/+1
| | | | | | | | Make -fno-PIC default on PowerPC for Little Endian Linux. Differential Revision: https://reviews.llvm.org/D53384 llvm-svn: 349489
* [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabledMartin Storsjo2018-12-181-0/+6
| | | | | | | | | | | | For targets where SEH exceptions are used by default (on MinGW, only x86_64 so far), -munwind-tables are added automatically. If -fseh-exeptions is enabled on a target where SEH exeptions are availble but not enabled by default yet (aarch64), we need to pass -munwind-tables if -fseh-exceptions was specified. Differential Revision: https://reviews.llvm.org/D55749 llvm-svn: 349452
* [ExprConstant] Handle compound assignment when LHS has integral type and RHS ↵Tan S. B.2018-12-181-7/+19
| | | | | | | | | | has floating point type Fixes PR39858 Differential Revision: https://reviews.llvm.org/D55413 llvm-svn: 349444
* Automatic variable initializationJF Bastien2018-12-184-13/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an option to initialize automatic variables with either a pattern or with zeroes. The default is still that automatic variables are uninitialized. Also add attributes to request uninitialized on a per-variable basis, mainly to disable initialization of large stack arrays when deemed too expensive. This isn't meant to change the semantics of C and C++. Rather, it's meant to be a last-resort when programmers inadvertently have some undefined behavior in their code. This patch aims to make undefined behavior hurt less, which security-minded people will be very happy about. Notably, this means that there's no inadvertent information leak when: - The compiler re-uses stack slots, and a value is used uninitialized. - The compiler re-uses a register, and a value is used uninitialized. - Stack structs / arrays / unions with padding are copied. This patch only addresses stack and register information leaks. There's many more infoleaks that we could address, and much more undefined behavior that could be tamed. Let's keep this patch focused, and I'm happy to address related issues elsewhere. To keep the patch simple, only some `undef` is removed for now, see `replaceUndef`. The padding-related infoleaks are therefore not all gone yet. This will be addressed in a follow-up, mainly because addressing padding-related leaks should be a stand-alone option which is implied by variable initialization. There are three options when it comes to automatic variable initialization: 0. Uninitialized This is C and C++'s default. It's not changing. Depending on code generation, a programmer who runs into undefined behavior by using an uninialized automatic variable may observe any previous value (including program secrets), or any value which the compiler saw fit to materialize on the stack or in a register (this could be to synthesize an immediate, to refer to code or data locations, to generate cookies, etc). 1. Pattern initialization This is the recommended initialization approach. Pattern initialization's goal is to initialize automatic variables with values which will likely transform logic bugs into crashes down the line, are easily recognizable in a crash dump, without being values which programmers can rely on for useful program semantics. At the same time, pattern initialization tries to generate code which will optimize well. You'll find the following details in `patternFor`: - Integers are initialized with repeated 0xAA bytes (infinite scream). - Vectors of integers are also initialized with infinite scream. - Pointers are initialized with infinite scream on 64-bit platforms because it's an unmappable pointer value on architectures I'm aware of. Pointers are initialize to 0x000000AA (small scream) on 32-bit platforms because 32-bit platforms don't consistently offer unmappable pages. When they do it's usually the zero page. As people try this out, I expect that we'll want to allow different platforms to customize this, let's do so later. - Vectors of pointers are initialized the same way pointers are. - Floating point values and vectors are initialized with a negative quiet NaN with repeated 0xFF payload (e.g. 0xffffffff and 0xffffffffffffffff). NaNs are nice (here, anways) because they propagate on arithmetic, making it more likely that entire computations become NaN when a single uninitialized value sneaks in. - Arrays are initialized to their homogeneous elements' initialization value, repeated. Stack-based Variable-Length Arrays (VLAs) are runtime-initialized to the allocated size (no effort is made for negative size, but zero-sized VLAs are untouched even if technically undefined). - Structs are initialized to their heterogeneous element's initialization values. Zero-size structs are initialized as 0xAA since they're allocated a single byte. - Unions are initialized using the initialization for the largest member of the union. Expect the values used for pattern initialization to change over time, as we refine heuristics (both for performance and security). The goal is truly to avoid injecting semantics into undefined behavior, and we should be comfortable changing these values when there's a worthwhile point in doing so. Why so much infinite scream? Repeated byte patterns tend to be easy to synthesize on most architectures, and otherwise memset is usually very efficient. For values which aren't entirely repeated byte patterns, LLVM will often generate code which does memset + a few stores. 2. Zero initialization Zero initialize all values. This has the unfortunate side-effect of providing semantics to otherwise undefined behavior, programs therefore might start to rely on this behavior, and that's sad. However, some programmers believe that pattern initialization is too expensive for them, and data might show that they're right. The only way to make these programmers wrong is to offer zero-initialization as an option, figure out where they are right, and optimize the compiler into submission. Until the compiler provides acceptable performance for all security-minded code, zero initialization is a useful (if blunt) tool. I've been asked for a fourth initialization option: user-provided byte value. This might be useful, and can easily be added later. Why is an out-of band initialization mecanism desired? We could instead use -Wuninitialized! Indeed we could, but then we're forcing the programmer to provide semantics for something which doesn't actually have any (it's uninitialized!). It's then unclear whether `int derp = 0;` lends meaning to `0`, or whether it's just there to shut that warning up. It's also way easier to use a compiler flag than it is to manually and intelligently initialize all values in a program. Why not just rely on static analysis? Because it cannot reason about all dynamic code paths effectively, and it has false positives. It's a great tool, could get even better, but it's simply incapable of catching all uses of uninitialized values. Why not just rely on memory sanitizer? Because it's not universally available, has a 3x performance cost, and shouldn't be deployed in production. Again, it's a great tool, it'll find the dynamic uses of uninitialized variables that your test coverage hits, but it won't find the ones that you encounter in production. What's the performance like? Not too bad! Previous publications [0] have cited 2.7 to 4.5% averages. We've commmitted a few patches over the last few months to address specific regressions, both in code size and performance. In all cases, the optimizations are generally useful, but variable initialization benefits from them a lot more than regular code does. We've got a handful of other optimizations in mind, but the code is in good enough shape and has found enough latent issues that it's a good time to get the change reviewed, checked in, and have others kick the tires. We'll continue reducing overheads as we try this out on diverse codebases. Is it a good idea? Security-minded folks think so, and apparently so does the Microsoft Visual Studio team [1] who say "Between 2017 and mid 2018, this feature would have killed 49 MSRC cases that involved uninitialized struct data leaking across a trust boundary. It would have also mitigated a number of bugs involving uninitialized struct data being used directly.". They seem to use pure zero initialization, and claim to have taken the overheads down to within noise. Don't just trust Microsoft though, here's another relevant person asking for this [2]. It's been proposed for GCC [3] and LLVM [4] before. What are the caveats? A few! - Variables declared in unreachable code, and used later, aren't initialized. This goto, Duff's device, other objectionable uses of switch. This should instead be a hard-error in any serious codebase. - Volatile stack variables are still weird. That's pre-existing, it's really the language's fault and this patch keeps it weird. We should deprecate volatile [5]. - As noted above, padding isn't fully handled yet. I don't think these caveats make the patch untenable because they can be addressed separately. Should this be on by default? Maybe, in some circumstances. It's a conversation we can have when we've tried it out sufficiently, and we're confident that we've eliminated enough of the overheads that most codebases would want to opt-in. Let's keep our precious undefined behavior until that point in time. How do I use it: 1. On the command-line: -ftrivial-auto-var-init=uninitialized (the default) -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 2. Using an attribute: int dont_initialize_me __attribute((uninitialized)); [0]: https://users.elis.ugent.be/~jsartor/researchDocs/OOPSLA2011Zero-submit.pdf [1]: https://twitter.com/JosephBialek/status/1062774315098112001 [2]: https://outflux.net/slides/2018/lss/danger.pdf [3]: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00615.html [4]: https://github.com/AndroidHardeningArchive/platform_external_clang/commit/776a0955ef6686d23a82d2e6a3cbd4a6a882c31c [5]: http://wg21.link/p1152 I've also posted an RFC to cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html <rdar://problem/39131435> Reviewers: pcc, kcc, rsmith Subscribers: JDevlieghere, jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D54604 llvm-svn: 349442
* Fix ms-layout_version declspec test and add missing new testReid Kleckner2018-12-171-6/+6
| | | | | | | | | | Now that MSVC compatibility versions are stored as a four digit number (1912) instead of a two digit number (19), we need to adjust how we handle this attribute. Also add a new test that was intended to be part of r349414. llvm-svn: 349415
* Update Microsoft name mangling scheme for exception specifiers in the type ↵Reid Kleckner2018-12-173-12/+24
| | | | | | | | | | | | | | | | | | | | | system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
* [analyzer] MoveChecker: Squash the bit field because it causes a GCC warning.Artem Dergachev2018-12-171-5/+3
| | | | | | | | | The warning seems spurious (GCC bug 51242), but the bit field is simply not worth the hassle. rdar://problem/41349073 llvm-svn: 349394
* [darwin][arm64] use the "cyclone" CPU for Darwin even when `-arch`Alex Lorenz2018-12-174-14/+25
| | | | | | | | | | | | | | | | is not specified The -target option allows the user to specify the build target using LLVM triple. The triple includes the arch, and so the -arch option is redundant. This should work just as well without the -arch. However, the driver has a bug in which it doesn't target the "Cyclone" CPU for darwin if -target is used without -arch. This commit fixes this issue. rdar://46743182 Differential Revision: https://reviews.llvm.org/D55731 llvm-svn: 349382
* [Driver] Don't override '-march' when using '-arch x86_64h'Francis Visoiu Mistrih2018-12-172-10/+2
| | | | | | | | | | | | On Darwin, using '-arch x86_64h' would always override the option passed through '-march'. This patch allows users to use '-march' with x86_64h, while keeping the default to 'core-avx2' Differential Revision: https://reviews.llvm.org/D55775 llvm-svn: 349381
* [darwin] parse the SDK settings from SDKSettings.json if it exists andAlex Lorenz2018-12-176-29/+148
| | | | | | | | | | | | | | | | | | | | pass in the -target-sdk-version to the compiler and backend This commit adds support for reading the SDKSettings.json file in the Darwin driver. This file is used by the driver to determine the SDK's version, and it uses that information to pass it down to the compiler using the new -target-sdk-version= option. This option is then used to set the appropriate SDK Version module metadata introduced in r349119. Note: I had to adjust the two ast tests as the SDKROOT environment variable on macOS caused SDK version to be picked up for the compilation of source file but not the AST. rdar://45774000 Differential Revision: https://reviews.llvm.org/D55673 llvm-svn: 349380
* [ASTImporter] Add importer specific lookupGabor Marton2018-12-175-93/+237
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are certain cases when normal C/C++ lookup (localUncachedLookup) does not find AST nodes. E.g.: Example 1: template <class T> struct X { friend void foo(); // this is never found in the DC of the TU. }; Example 2: // The fwd decl to Foo is not found in the lookupPtr of the DC of the // translation unit decl. struct A { struct Foo *p; }; In these cases we create a new node instead of returning with the old one. To fix it we create a new lookup table which holds every node and we are not interested in any C++ specific visibility considerations. Simply, we must know if there is an existing Decl in a given DC. Reviewers: a_sidorin, a.sidorin Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, cfe-commits Differential Revision: https://reviews.llvm.org/D53708 llvm-svn: 349351
* [ASTImporter] Fix redecl chain of classes and class templatesGabor Marton2018-12-174-173/+167
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The crux of the issue that is being fixed is that lookup could not find previous decls of a friend class. The solution involves making the friend declarations visible in their decl context (i.e. adding them to the lookup table). Also, we simplify `VisitRecordDecl` greatly. This fix involves two other repairs (without these the unittests fail): (1) We could not handle the addition of injected class types properly when a redecl chain was involved, now this is fixed. (2) DeclContext::removeDecl failed if the lookup table in Vector form did not contain the to be removed element. This caused troubles in ASTImporter::ImportDeclContext. This is also fixed. Reviewers: a_sidorin, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits Differential Revision: https://reviews.llvm.org/D53655 llvm-svn: 349349
* Revert rC349281 '[analyzer][MallocChecker][NFC] Document and reorganize some ↵Kristof Umann2018-12-171-714/+422
| | | | | | | | | | 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
* Fix "enumeral mismatch in conditional expression" gcc7 warning. NFCI.Simon Pilgrim2018-12-171-3/+4
| | | | llvm-svn: 349343
* Fix "enumeral mismatch in conditional expression" gcc7 warnings. NFCI.Simon Pilgrim2018-12-172-20/+21
| | | | llvm-svn: 349342
* Revert rC349281 '[analyzer][MallocChecker][NFC] Document and reorganize some ↵Kristof Umann2018-12-171-11/+3
| | | | | | functions' llvm-svn: 349340
* Reverting bitfield size to attempt to fix a windows buildbotKristof Umann2018-12-171-1/+1
| | | | llvm-svn: 349336
* [analyzer] MoveChecker: Add an option to suppress warnings on locals.Artem Dergachev2018-12-171-9/+29
| | | | | | | | | | | | | | | | | Re-using a moved-from local variable is most likely a bug because there's rarely a good motivation for not introducing a separate variable instead. We plan to keep emitting such warnings by default. Introduce a flag that allows disabling warnings on local variables that are not of a known move-unsafe type. If it doesn't work out as we expected, we'll just flip the flag. We still warn on move-unsafe objects and unsafe operations on known move-safe objects. Differential Revision: https://reviews.llvm.org/D55730 llvm-svn: 349327
* Speculatively re-apply "[analyzer] MoveChecker: Add checks for dereferencing..."Artem Dergachev2018-12-171-51/+149
| | | | | | | | | | | | This re-applies commit r349226 that was reverted in r349233 due to failures on clang-x64-windows-msvc. Specify enum type as unsigned for use in bit field. Otherwise overflows may cause UB. Differential Revision: https://reviews.llvm.org/D55388 llvm-svn: 349326
* [analyzer] Fix some expressions staying live too long. Add a debug checker.Artem Dergachev2018-12-162-0/+67
| | | | | | | | | | | | | | | | | | | | | StaticAnalyzer uses the CFG-based RelaxedLiveVariables analysis in order to, in particular, figure out values of which expressions are still needed. When the expression becomes "dead", it is garbage-collected during the dead binding scan. Expressions that constitute branches/bodies of control flow statements, eg. `E1' in `if (C1) E1;' but not `E2' in `if (C2) { E2; }', were kept alive for too long. This caused false positives in MoveChecker because it relies on cleaning up loop-local variables when they go out of scope, but some of those live-for-too-long expressions were keeping a reference to those variables. Fix liveness analysis to correctly mark these expressions as dead. Add a debug checker, debug.DumpLiveStmts, in order to test expressions liveness. Differential Revision: https://reviews.llvm.org/D55566 llvm-svn: 349320
* Thread safety analysis: Avoid intermediate copies [NFC]Aaron Puchert2018-12-161-21/+31
| | | | | | | The main reason is to reduce the number of constructor arguments though, especially since many of them had the same type. llvm-svn: 349308
* Thread safety analysis: Allow scoped releasing of capabilitiesAaron Puchert2018-12-161-39/+73
| | | | | | | | | | | | | | | | | | | | | | Summary: The pattern is problematic with C++ exceptions, and not as widespread as scoped locks, but it's still used by some, for example Chromium. We are a bit stricter here at join points, patterns that are allowed for scoped locks aren't allowed here. That could still be changed in the future, but I'd argue we should only relax this if people ask for it. Fixes PR36162. Reviewers: aaron.ballman, delesley, pwnall Reviewed By: delesley, pwnall Subscribers: pwnall, cfe-commits Differential Revision: https://reviews.llvm.org/D52578 llvm-svn: 349300
* [analyzer][MallocChecker] Improve warning messages on double-delete errorsKristof Umann2018-12-151-2/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D54834 llvm-svn: 349283
* [analyzer][MallocChecker][NFC] Document and reorganize some functionsKristof Umann2018-12-151-422/+714
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer][NFC] Merge ClangCheckerRegistry to CheckerRegistryKristof Umann2018-12-153-100/+76
| | | | | | | | | | | Now that CheckerRegistry lies in Frontend, we can finally eliminate ClangCheckerRegistry. Fortunately, this also provides us with a DiagnosticsEngine, so I went ahead and removed some parameters from it's methods. Differential Revision: https://reviews.llvm.org/D54437 llvm-svn: 349280
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-15102-170/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] Prefer returns values to out-params in CheckerRegistry.cppKristof Umann2018-12-153-96/+55
| | | | | | | | | | | | | | | Renaming collectCheckers to getEnabledCheckers Changing the functionality to acquire all enabled checkers, rather then collect checkers for a specific CheckerOptInfo (for example, collecting all checkers for { "core", true }, which meant enabling all checkers from the core package, which was an unnecessary complication). Removing CheckerOptInfo, instead of storing whether the option was claimed via a field, we handle errors immediately, as getEnabledCheckers can now access a DiagnosticsEngine. Realize that the remaining information it stored is directly accessible through AnalyzerOptions.CheckerControlList. Fix a test with -analyzer-disable-checker -verify accidentally left in. llvm-svn: 349274
* [analyzer] Assume that we always have a SubEngine availableGabor Horvath2018-12-157-49/+36
| | | | | | | | The removed codepath was dead. Differential Revision: https://reviews.llvm.org/D55697 llvm-svn: 349266
* [MinGW] Produce a vtable and RTTI for dllexported classes without a key functionMartin Storsjo2018-12-151-0/+3
| | | | | | | | | | | | | | This matches what GCC does in these situations. This fixes compiling Qt in debug mode. In release mode, references to the vtable of this particular class ends up optimized away, but in debug mode, the compiler creates references to the vtable, which is expected to be dllexported from a different DLL. Make sure the dllexported version actually ends up emitted. Differential Revision: https://reviews.llvm.org/D55698 llvm-svn: 349256
* Revert "[analyzer] MoveChecker: Add checks for dereferencing a smart pointer..."Artem Dergachev2018-12-151-149/+51
| | | | | | | | This reverts commit r349226. Fails on an MSVC buildbot. llvm-svn: 349233
* Move static analyzer core diagnostics to common.Richard Trieu2018-12-151-1/+0
| | | | llvm-svn: 349230
* [analyzer] Fix unknown block calls to have zero parameters.Artem Dergachev2018-12-151-1/+1
| | | | | | | | | | | | Right now they report to have one parameter with null decl, because initializing an ArrayRef of pointers with a nullptr yields an ArrayRef to an array of one null pointer. Fixes a crash in the OSObject section of RetainCountChecker. Differential Revision: https://reviews.llvm.org/D55671 llvm-svn: 349229
* [analyzer] ObjCDealloc: Fix a crash when a class attempts to deallocate a class.Artem Dergachev2018-12-151-0/+4
| | | | | | | | | | | | | | | | | | The checker wasn't prepared to see the dealloc message sent to the class itself rather than to an instance, as if it was +dealloc. Additionally, it wasn't prepared for pure-unknown or undefined self values. The new guard covers that as well, but it is annoying to test because both kinds of values shouldn't really appear and we generally want to get rid of all of them (by modeling unknown values with symbols and by warning on use of undefined values before they are used). The CHECK: directive for FileCheck at the end of the test looks useless, so i removed it. Differential Revision: https://reviews.llvm.org/D55680 llvm-svn: 349228
* [analyzer] ObjCContainers: Track index values.Artem Dergachev2018-12-151-0/+17
| | | | | | | | | | | | Use trackExpressionValue() (previously known as trackNullOrUndefValue()) to track index value in the report, so that the user knew what Static Analyzer thinks the index is. Additionally, implement printState() to help debugging the checker later. Differential Revision: https://reviews.llvm.org/D55458 llvm-svn: 349227
* [analyzer] MoveChecker: Add checks for dereferencing a smart pointer after move.Artem Dergachev2018-12-151-51/+149
| | | | | | | | | | | | | | | | | | | Calling operator*() or operator->() on a null STL smart pointer is undefined behavior. Smart pointers are specified to become null after being moved from. So we can't warn on arbitrary method calls, but these two operators definitely make no sense. The new bug is fatal because it's an immediate UB, unlike other use-after-move bugs. The work on a more generic null smart pointer dereference checker is still pending. Differential Revision: https://reviews.llvm.org/D55388 llvm-svn: 349226
OpenPOWER on IntegriCloud