summaryrefslogtreecommitdiffstats
path: root/clang/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* Thread Safety: also look at ObjC methodsJF Bastien2019-03-251-8/+13
| | | | | | | | | | | | | | | | | Summary: SExprBuilder::translateDeclRefExpr was only looking at FunctionDecl and not also looking at ObjCMethodDecl. It should consider both because the attributes can be used on Objective-C as well. <rdar://problem/48941331> Reviewers: dexonsmith, erik.pilkington Subscribers: jkorous, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59523 llvm-svn: 356940
* [CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in constructors.Artem Dergachev2019-03-211-0/+9
| | | | | | | | | | | | | | When searching for construction contexts, i.e. figuring out which statements define the object that is constructed by each construct-expression, ignore transparent init-list expressions because they don't add anything to the context. This allows the Static Analyzer to model construction, destruction, materialization, lifetime extension correctly in more cases. Also fixes a crash caused by incorrectly evaluating initial values of variables initialized with such expressions. Differential Revision: https://reviews.llvm.org/D59573 llvm-svn: 356634
* Thread safety analysis: Add note for unlock kind mismatchAaron Puchert2019-03-181-2/+2
| | | | | | | | | | | | | | | | | | Summary: Similar to D56967, we add the existing diag::note_locked_here to tell the user where we saw the locking that isn't matched correctly. Reviewers: aaron.ballman, delesley Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59455 llvm-svn: 356427
* [analyzer] RetainCount: A function isn't a CFRetain if it takes no arguments.Artem Dergachev2019-03-151-6/+7
| | | | | | | | | | | | | Don't crash when a function has a name that starts with "CF" and ends with "Retain" but takes 0 arguments. In particular, don't try to treat it as if it returns its first argument. These problems are inevitable because the checker is naming-convention-based, but at least we shouldn't crash. Differential Revision: https://reviews.llvm.org/D59123 llvm-svn: 356223
* [analyzer] handle modification of vars inside an expr with comma operatorPetar Jovanovic2019-03-071-13/+33
| | | | | | | | | | | | | | | | | We should track mutation of a variable within a comma operator expression. Current code in ExprMutationAnalyzer does not handle it. This will handle cases like: (a, b) ++ < == b is modified (a, b) = c < == b is modifed Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D58894 llvm-svn: 355605
* Fix file headers. NFCFangrui Song2019-03-011-1/+1
| | | | llvm-svn: 355176
* Revert "[Analysis] -Wunreachable-code shouldn't fire on the increment of a ↵Sam McCall2019-02-151-4/+0
| | | | | | | | foreach loop" This reverts commit r354102. llvm-svn: 354109
* [Analysis] -Wunreachable-code shouldn't fire on the increment of a foreach loopSam McCall2019-02-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The idea is that the code here isn't written, so doesn't indicate a bug. Similar to code expanded from macros. This means the warning no longer fires on this code: for (auto C : collection) { process(C); return; } handleEmptyCollection(); Unclear whether this is more often a bug or not in practice, I think it's a reasonable idiom in some cases. Either way, if we want to warn on "loop that doesn't loop", I think it should be a separate warning, and catch `while(1) break;` Reviewers: ilya-biryukov, ioeric Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58134 llvm-svn: 354102
* [analyzer] [RetainCountChecker] Bugfix: in non-OSObject-mode, do not track ↵George Karpenkov2019-02-051-6/+6
| | | | | | | | CXX method calls Differential Revision: https://reviews.llvm.org/D57782 llvm-svn: 353227
* [AST] Update the comments of the various Expr::Ignore* + Related cleanupsBruno Ricci2019-02-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The description of what the various Expr::Ignore* do has drifted from the actual implementation. Inspection reveals that IgnoreParenImpCasts() is not equivalent to doing IgnoreParens() + IgnoreImpCasts() until reaching a fixed point, but IgnoreParenCasts() is equivalent to doing IgnoreParens() + IgnoreCasts() until reaching a fixed point. There is also a fair amount of duplication in the various Expr::Ignore* functions which increase the chance of further future inconsistencies. In preparation for the next patch which will factor out the implementation of the various Expr::Ignore*, do the following cleanups: Remove Stmt::IgnoreImplicit, in favor of Expr::IgnoreImplicit. IgnoreImplicit is the only function among all of the Expr::Ignore* which is available in Stmt. There are only a few users of Stmt::IgnoreImplicit. They can just use instead Expr::IgnoreImplicit like they have to do for the other Ignore*. Move Expr::IgnoreImpCasts() from Expr.h to Expr.cpp. This made no difference in the run-time with my usual benchmark (-fsyntax-only on all of Boost). While we are at it, make IgnoreParenNoopCasts take a const reference to the ASTContext for const correctness. Update the comments to match what the Expr::Ignore* are actually doing. I am not sure that listing exactly what each Expr::Ignore* do is optimal, but it certainly looks better than the current state which is in my opinion between misleading and just plain wrong. The whole patch is NFC (if you count removing Stmt::IgnoreImplicit as NFC). Differential Revision: https://reviews.llvm.org/D57266 Reviewed By: aaron.ballman llvm-svn: 353006
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* [analyzer] [RetainCountChecker] Bugfix for tracking top-level parameters of ↵George Karpenkov2019-01-301-2/+2
| | | | | | | | Objective-C methods Differential Revision: https://reviews.llvm.org/D57433 llvm-svn: 352588
* Thread safety analysis: Improve diagnostics for double lockingAaron Puchert2019-01-291-4/+5
| | | | | | | | | | | | | | | | Summary: We use the existing diag::note_locked_here to tell the user where we saw the first locking. Reviewers: aaron.ballman, delesley Reviewed By: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56967 llvm-svn: 352549
* [analyzer] [RetainCountChecker] Track input parameters to the top-level functionGeorge Karpenkov2019-01-291-1/+44
| | | | | | | | | | Track them for ISL/OS objects by default, and for NS/CF under a flag. rdar://47536377 Differential Revision: https://reviews.llvm.org/D57356 llvm-svn: 352534
* [analyzer] [RetainSummaryManager] [NFC] Split one function into two, as it's ↵George Karpenkov2019-01-291-56/+42
| | | | | | | | really doing two things Differential Revision: https://reviews.llvm.org/D57201 llvm-svn: 352533
* [analyzer] [ARCMT] [NFC] Unify entry point into RetainSummaryManagerGeorge Karpenkov2019-01-291-31/+6
| | | | | | | | Just use one single entry point, since we have AnyCall utility now. Differential Revision: https://reviews.llvm.org/D57346 llvm-svn: 352532
* [analyzer] [RetainCountChecker] Support 'taggedRetain' and 'taggedRelease'George Karpenkov2019-01-291-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D57211 llvm-svn: 352530
* [analyzer] Port RetainSummaryManager to the new AnyCall interface, decouple ↵George Karpenkov2019-01-252-0/+1269
| | | | | | | | | | ARCMT from the analyzer rdar://19694750 Differential Revision: https://reviews.llvm.org/D57127 llvm-svn: 352149
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1923-92/+69
| | | | | | | | | | | | | | | | | 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] Do not try to body-farm Objective-C properties with custom accessors.Artem Dergachev2019-01-181-0/+5
| | | | | | | | | | | | | | | | If a property is defined with a custom getter, we should not behave as if the getter simply returns an instance variable. We don't support setters, so they aren't affected. On top of being the right thing to do, this also fixes a crash on the newly added test - in which a property and its getter are defined in two separate categories. rdar://problem/47051544 Differential Revision: https://reviews.llvm.org/D56823 llvm-svn: 351609
* [AST] Remove ASTContext from getThisType (NFC)Brian Gesiak2019-01-111-10/+6
| | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from within the `CXXMethodDecl::getThisType` method. Remove the parameter altogether, as well as all usages of it. This does not result in any functional change because the parameter was unused since https://reviews.llvm.org/D54862. Test Plan: check-clang Reviewers: akyrtzi, mikael Reviewed By: mikael Subscribers: mehdi_amini, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56509 llvm-svn: 350914
* [AST] Store the callee and argument expressions of CallExpr in a trailing array.Bruno Ricci2018-12-211-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since CallExpr::setNumArgs has been removed, it is now possible to store the callee expression and the argument expressions of CallExpr in a trailing array. This saves one pointer per CallExpr, CXXOperatorCallExpr, CXXMemberCallExpr, CUDAKernelCallExpr and UserDefinedLiteral. Given that CallExpr is used as a base of the above classes we cannot use llvm::TrailingObjects. Instead we store the offset in bytes from the this pointer to the start of the trailing objects and manually do the casts + arithmetic. Some notes: 1.) I did not try to fit the number of arguments in the bit-fields of Stmt. This leaves some space for future additions and avoid the discussion about whether x bits are sufficient to hold the number of arguments. 2.) It would be perfectly possible to recompute the offset to the trailing objects before accessing the trailing objects. However the trailing objects are frequently accessed and benchmarks show that it is slightly faster to just load the offset from the bit-fields. Additionally, because of 1), we have plenty of space in the bit-fields of Stmt. Differential Revision: https://reviews.llvm.org/D55771 Reviewed By: rjmccall llvm-svn: 349910
* [AST][NFC] Pass the AST context to one of the ctor of DeclRefExpr.Bruno Ricci2018-12-212-4/+7
| | | | | | | | | All of the other constructors already take a reference to the AST context. This avoids calling Decl::getASTContext in most cases. Additionally move the definition of the constructor from Expr.h to Expr.cpp since it is calling DeclRefExpr::computeDependence. NFC. llvm-svn: 349901
* [analyzer] Fix some expressions staying live too long. Add a debug checker.Artem Dergachev2018-12-161-0/+48
| | | | | | | | | | | | | | | | | | | | | 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
* Change CallGraph print to show the fully qualified nameErich Keane2018-12-121-1/+1
| | | | | | | | | | CallGraph previously would just show the normal name of a function, which gets really confusing when using it on large C++ projects. This patch switches the printName call to a printQualifiedName, so that the namespaces are included. Change-Id: Ie086d863f6b2251be92109ea1b0946825b28b49a llvm-svn: 348950
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-101-1/+1
| | | | | | | | | | | | | | 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
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-7/+12
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-12/+7
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-7/+12
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-7/+12
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-12/+7
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-7/+12
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Compound literals, enums, et al require const exprBill Wendling2018-11-091-0/+12
| | | | | | | | | | | | | | | | | | Summary: Compound literals, enums, file-scoped arrays, etc. require their initializers and size specifiers to be constant. Wrap the initializer expressions in a ConstantExpr so that we can easily check for this later on. Reviewers: rsmith, shafik Reviewed By: rsmith Subscribers: cfe-commits, jyknight, nickdesaulniers Differential Revision: https://reviews.llvm.org/D53921 llvm-svn: 346455
* [coroutines] Fix fallthrough warning on try/catchBrian Gesiak2018-11-031-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The test case added in this diff would incorrectly warn that control flow may fall through without returning. Here's a standalone example: https://godbolt.org/z/dCwXEi The same program, but using `return` instead of `co_return`, does not produce a warning: https://godbolt.org/z/mVldqQ The issue was in how Clang analysis would structure its representation of the control-flow graph. Specifically, when constructing the CFG, `CFGBuilder::Visit` had special handling of a `ReturnStmt`, in which it would place object destructors in the same CFG block as a `return` statement, immediately after it. Doing so would allow the logic in `lib/Sema/AnalysisBasedWarning.cpp` `CheckFallThrough` to work properly in the program that used `return`, correctly determining that no "plain edges" preceded the exit block of the function. Because a `co_return` statement would not enjoy the same treatment when it was being built into the control-flow graph, object destructors would not be placed in the same CFG block as the `co_return`, thus resulting in a "plain edge" preceding the exit block of the function, and so the warning logic would be triggered. Add special casing for `co_return` to Clang analysis, thereby remedying the mistaken warning. Test Plan: `check-clang` Reviewers: GorNishanov, tks2103, rsmith Reviewed By: GorNishanov Subscribers: EricWF, lewissbaker, cfe-commits Differential Revision: https://reviews.llvm.org/D54075 llvm-svn: 346074
* Reapply Logging: make os_log buffer size an integer constant expression.Tim Northover2018-11-026-2833/+0
| | | | | | | | | | | | The size of an os_log buffer is known at any stage of compilation, so making it a constant expression means that the common idiom of declaring a buffer for it won't result in a VLA. That allows the compiler to skip saving and restoring the stack pointer around such buffers. This also moves the OSLog and other FormatString helpers from libclangAnalysis to libclangAST to avoid a circular dependency. llvm-svn: 345971
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-013-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* Revert "Reapply Logging: make os_log buffer size an integer constant ↵Tim Northover2018-11-013-1/+205
| | | | | | | | expression." Still more dependency hell. llvm-svn: 345871
* Reapply Logging: make os_log buffer size an integer constant expression.Tim Northover2018-11-013-205/+1
| | | | | | | | | | | | The size of an os_log buffer is known at any stage of compilation, so making it a constant expression means that the common idiom of declaring a buffer for it won't result in a VLA. That allows the compiler to skip saving and restoring the stack pointer around such buffers. This also moves the OSLog helpers from libclangAnalysis to libclangAST to avoid a circular dependency. llvm-svn: 345866
* Create ConstantExpr classBill Wendling2018-10-313-4/+6
| | | | | | | | | | | | | | | | A ConstantExpr class represents a full expression that's in a context where a constant expression is required. This class reflects the path the evaluator took to reach the expression rather than the syntactic context in which the expression occurs. In the future, the class will be expanded to cache the result of the evaluated expression so that it's not needlessly re-evaluated Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D53475 llvm-svn: 345692
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-301-1/+1
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* [AST] Only store data for the NRVO candidate in ReturnStmt if neededBruno Ricci2018-10-301-3/+2
| | | | | | | | | | | | | Only store the NRVO candidate if needed in ReturnStmt. A good chuck of all of the ReturnStmt have no NRVO candidate (more than half when parsing all of Boost). For all of them this saves one pointer. This has no impact on children(). Differential Revision: https://reviews.llvm.org/D53716 Reviewed By: rsmith llvm-svn: 345605
* [AST] Only store the needed data in IfStmtBruno Ricci2018-10-271-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | Only store the needed data in IfStmt. This cuts the size of IfStmt by up to 3 pointers + 1 SourceLocation. The order of the children is intentionally kept the same even though it would be more convenient to put the optional trailing objects last. Additionally use the newly available space in the bit-fields of Stmt to store the location of the "if". The result of this is that for the common case of an if statement of the form: if (some_cond) some_statement the size of IfStmt is brought down to 8 bytes + 2 pointers, instead of 8 bytes + 5 pointers + 2 SourceLocation. Differential Revision: https://reviews.llvm.org/D53607 Reviewed By: rjmccall llvm-svn: 345464
* Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFCFangrui Song2018-10-201-2/+1
| | | | llvm-svn: 344859
* Thread safety analysis: Handle conditional expression in getTrylockCallExprAaron Puchert2018-10-061-1/+13
| | | | | | | | | | | | | | | | | | | | | Summary: We unwrap conditional expressions containing try-lock functions. Additionally we don't acquire on conditional expression branches, since that is usually not helpful. When joining the branches we would almost certainly get a warning then. Hopefully fixes an issue that was raised in D52398. Reviewers: aaron.ballman, delesley, hokein Reviewed By: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52888 llvm-svn: 343902
* Thread safety analysis: Examine constructor argumentsAaron Puchert2018-10-041-51/+49
| | | | | | | | | | | | | | | | | | | | Summary: Instead of only examining call arguments, we also examine constructor arguments applying the same rules. That was an opportunity for refactoring the examination procedure to work with iterators instead of integer indices. For the case of CallExprs no functional change is intended. Reviewers: aaron.ballman, delesley Reviewed By: delesley Subscribers: JonasToth, cfe-commits Differential Revision: https://reviews.llvm.org/D52443 llvm-svn: 343831
* Thread safety analysis: Unwrap __builtin_expect in getTrylockCallExprAaron Puchert2018-10-031-1/+5
| | | | | | | | | | | | | | | | | | Summary: When people are really sure they'll get the lock they sometimes use __builtin_expect. It's also used by some assertion implementations. Asserting that try-lock succeeded is basically the same as asserting that the lock is not held by anyone else (and acquiring it). Reviewers: aaron.ballman, delesley Reviewed By: aaron.ballman Subscribers: kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D52398 llvm-svn: 343681
* [analyzer] Fix crash in exploded graph dumpingGeorge Karpenkov2018-10-021-4/+1
| | | | | | | | By allocating new DeclStmt to ASTContext Differential Revision: https://reviews.llvm.org/D52756 llvm-svn: 343635
OpenPOWER on IntegriCloud