aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Analysis/ThreadSafetyCommon.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-05-31[Analysis] Remove unused includes (NFC) (#142255)Kazu Hirata1-1/+0
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2025-05-26Thread Safety Analysis: Support reentrant capabilities (#137133)Marco Elver1-37/+39
Introduce the `reentrant_capability` attribute, which may be specified alongside the `capability(..)` attribute to denote that the defined capability type is reentrant. Marking a capability as reentrant means that acquiring the same capability multiple times is safe, and does not produce warnings on attempted re-acquisition. The most significant changes required are plumbing to propagate if the attribute is present to a CapabilityExpr, and introducing ReentrancyDepth to the LockableFactEntry class.
2025-01-13[Analysis] Migrate away from PointerUnion::dyn_cast (NFC) (#122652)Kazu Hirata1-1/+1
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h: // FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T> Literal migration would result in dyn_cast_if_present (see the definition of PointerUnion::dyn_cast), but this patch uses dyn_cast because we expect Ctx->FunArgs to be nonnull.
2024-12-14Thread safety analysis: Fix substitution for operator calls (#116487)Aaron Puchert1-2/+18
For operator calls that go to methods we need to substitute the first parameter for "this" and the following parameters into the function parameters, instead of substituting all of them into the parameters. This revealed an issue about lambdas. An existing test accidentally worked because the substitution bug was covered by a speciality of lambdas: a CXXThisExpr in a lambda CXXMethodDecl does not refer to the implicit this argument of the method, but to a captured "this" from the context the lambda was created in. This can happen for operator calls, where it worked due to the substitution bug (we treated the implicit this argument incorrectly as parameter), and for regular calls (i.e. obj.operator()(args) instead of obj(args)), where it didn't work. The correct fix seems to be to clear the self-argument on a lambda call. Lambdas can only capture "this" inside methods, and calls to the lambda in that scope cannot substitute anything for "this".
2024-12-12[clang] Migrate away from PointerUnion::{is,get} (NFC) (#119724)Kazu Hirata1-1/+1
Note that PointerUnion::{is,get} have been soft deprecated in PointerUnion.h: // FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T> I'm not touching PointerUnion::dyn_cast for now because it's a bit complicated; we could blindly migrate it to dyn_cast_if_present, but we should probably use dyn_cast when the operand is known to be non-null.
2024-07-31[clang][NFC] Add Type::isPointerOrReferenceType() (#101206)Timm Baeder1-1/+1
Seems to be a common pattern.
2024-05-18[clang][ThreadSafety] Skip past implicit cast in `translateAttrExpr`Antonio Frighetto1-1/+1
Ignore `ImplicitCastExpr` when building `AttrExp` for capability attribute diagnostics. Fixes: https://github.com/llvm/llvm-project/issues/92118.
2024-05-16[clang] Drop explicit conversions of string literals to StringRef (NFC)Kazu Hirata1-1/+1
We routinely rely on implicit conversions of string literals to StringRef so that we can use operator==(StringRef, StringRef). The LHS here are all known to be of StringRef.
2024-02-26Thread safety analysis: provide printSCFG definition. (#80277)Haojian Wu1-2/+2
I called this function when investigating the issue (https://github.com/llvm/llvm-project/issues/78131), and I was surprised to see the definition is commented out. I think it makes sense to provide the definition even though the implementation is not stable.
2023-10-02[C++] Implement "Deducing this" (P0847R7)Corentin Jabot1-1/+3
This patch implements P0847R7 (partially), CWG2561 and CWG2653. Reviewed By: aaron.ballman, #clang-language-wg Differential Revision: https://reviews.llvm.org/D140828
2023-09-19[clang][TSA] Thread safety cleanup functionsTimm Bäder1-4/+15
Consider cleanup functions in thread safety analysis. Differential Revision: https://reviews.llvm.org/D152504
2023-06-13[clang] Use DenseMapBase::lookup (NFC)Kazu Hirata1-6/+1
2022-10-13Thread safety analysis: Support copy-elided production of scoped ↵Aaron Puchert1-17/+29
capabilities through arbitrary calls When support for copy elision was initially added in e97654b2f2807, it was taking attributes from a constructor call, although that constructor call is actually not involved. It seems more natural to use attributes on the function returning the scoped capability, which is where it's actually coming from. This would also support a number of interesting use cases, like producing different scope kinds without the need for tag types, or producing scopes from a private mutex. Changing the behavior was surprisingly difficult: we were not handling CXXConstructorExpr calls like regular calls but instead handled them through the DeclStmt they're contained in. This was based on the assumption that constructors are basically only called in variable declarations (not true because of temporaries), and that variable declarations necessitate constructors (not true with C++17 anymore). Untangling this required separating construction from assigning a variable name. When a call produces an object, we use a placeholder til::LiteralPtr for `this`, and we collect the call expression and placeholder in a map. Later when going through a DeclStmt, we look up the call expression and set the placeholder to the new VarDecl. The change has a couple of nice side effects: * We don't miss constructor calls not contained in DeclStmts anymore, allowing patterns like MutexLock{&mu}, requiresMutex(); The scoped lock temporary will be destructed at the end of the full statement, so it protects the following call without the need for a scope, but with the ability to unlock in case of an exception. * We support lifetime extension of temporaries. While unusual, one can now write const MutexLock &scope = MutexLock(&mu); and have it behave as expected. * Destructors used to be handled in a weird way: since there is no expression in the AST for implicit destructor calls, we instead provided a made-up DeclRefExpr to the variable being destructed, and passed that instead of a CallExpr. Then later in translateAttrExpr there was special code that knew that destructor expressions worked a bit different. * We were producing dummy DeclRefExprs in a number of places, this has been eliminated. We now use til::SExprs instead. Technically this could break existing code, but the current handling seems unexpected enough to justify this change. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D129755
2022-10-07Revert "Thread safety analysis: Support copy-elided production of scoped ↵Hans Wennborg1-29/+17
capabilities through arbitrary calls" This caused false positives, see comment on the code review. > When support for copy elision was initially added in e97654b2f2807, it > was taking attributes from a constructor call, although that constructor > call is actually not involved. It seems more natural to use attributes > on the function returning the scoped capability, which is where it's > actually coming from. This would also support a number of interesting > use cases, like producing different scope kinds without the need for tag > types, or producing scopes from a private mutex. > > Changing the behavior was surprisingly difficult: we were not handling > CXXConstructorExpr calls like regular calls but instead handled them > through the DeclStmt they're contained in. This was based on the > assumption that constructors are basically only called in variable > declarations (not true because of temporaries), and that variable > declarations necessitate constructors (not true with C++17 anymore). > > Untangling this required separating construction from assigning a > variable name. When a call produces an object, we use a placeholder > til::LiteralPtr for `this`, and we collect the call expression and > placeholder in a map. Later when going through a DeclStmt, we look up > the call expression and set the placeholder to the new VarDecl. > > The change has a couple of nice side effects: > * We don't miss constructor calls not contained in DeclStmts anymore, > allowing patterns like > MutexLock{&mu}, requiresMutex(); > The scoped lock temporary will be destructed at the end of the full > statement, so it protects the following call without the need for a > scope, but with the ability to unlock in case of an exception. > * We support lifetime extension of temporaries. While unusual, one can > now write > const MutexLock &scope = MutexLock(&mu); > and have it behave as expected. > * Destructors used to be handled in a weird way: since there is no > expression in the AST for implicit destructor calls, we instead > provided a made-up DeclRefExpr to the variable being destructed, and > passed that instead of a CallExpr. Then later in translateAttrExpr > there was special code that knew that destructor expressions worked a > bit different. > * We were producing dummy DeclRefExprs in a number of places, this has > been eliminated. We now use til::SExprs instead. > > Technically this could break existing code, but the current handling > seems unexpected enough to justify this change. > > Reviewed By: aaron.ballman > > Differential Revision: https://reviews.llvm.org/D129755 This reverts commit 0041a69495f828f6732803cfb0f1e3fddd7fbf2a and the follow-up warning fix in 83d93d3c11ac9727bf3d4c5c956de44233cc7f87.
2022-10-06Thread safety analysis: Support copy-elided production of scoped ↵Aaron Puchert1-17/+29
capabilities through arbitrary calls When support for copy elision was initially added in e97654b2f2807, it was taking attributes from a constructor call, although that constructor call is actually not involved. It seems more natural to use attributes on the function returning the scoped capability, which is where it's actually coming from. This would also support a number of interesting use cases, like producing different scope kinds without the need for tag types, or producing scopes from a private mutex. Changing the behavior was surprisingly difficult: we were not handling CXXConstructorExpr calls like regular calls but instead handled them through the DeclStmt they're contained in. This was based on the assumption that constructors are basically only called in variable declarations (not true because of temporaries), and that variable declarations necessitate constructors (not true with C++17 anymore). Untangling this required separating construction from assigning a variable name. When a call produces an object, we use a placeholder til::LiteralPtr for `this`, and we collect the call expression and placeholder in a map. Later when going through a DeclStmt, we look up the call expression and set the placeholder to the new VarDecl. The change has a couple of nice side effects: * We don't miss constructor calls not contained in DeclStmts anymore, allowing patterns like MutexLock{&mu}, requiresMutex(); The scoped lock temporary will be destructed at the end of the full statement, so it protects the following call without the need for a scope, but with the ability to unlock in case of an exception. * We support lifetime extension of temporaries. While unusual, one can now write const MutexLock &scope = MutexLock(&mu); and have it behave as expected. * Destructors used to be handled in a weird way: since there is no expression in the AST for implicit destructor calls, we instead provided a made-up DeclRefExpr to the variable being destructed, and passed that instead of a CallExpr. Then later in translateAttrExpr there was special code that knew that destructor expressions worked a bit different. * We were producing dummy DeclRefExprs in a number of places, this has been eliminated. We now use til::SExprs instead. Technically this could break existing code, but the current handling seems unexpected enough to justify this change. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D129755
2022-09-03[clang] Qualify auto in range-based for loops (NFC)Kazu Hirata1-1/+1
2022-04-29Thread safety analysis: Store capability kind in CapabilityExprAaron Puchert1-6/+31
This should make us print the right capability kind in many more cases, especially when attributes name multiple capabilities of different kinds. Previously we were trying to deduce the capability kind from the original attribute, but most attributes can name multiple capabilities, which could be of different kinds. So instead we derive the kind when translating the attribute expression, and then store it in the returned CapabilityExpr. Then we can extract the corresponding capability name when we need it, which saves us lots of plumbing and almost guarantees that the name is right. I didn't bother adding any tests for this because it's just a usability improvement and it's pretty much evident from the code that we don't fall back to "mutex" anymore (save for a few cases that I'll address in a separate change). Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D124131
2021-06-11[ADT] Remove APInt/APSInt toString() std::string variantsSimon Pilgrim1-1/+2
<string> is currently the highest impact header in a clang+llvm build: https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps. This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code. Differential Revision: https://reviews.llvm.org/D103888
2020-10-25Thread safety analysis: Nullability improvements in TIL, NFCIAaron Puchert1-2/+2
The constructor of Project asserts that the contained ValueDecl is not null, use that in the ThreadSafetyAnalyzer. In the case of LiteralPtr it's the other way around. Also dyn_cast<> is sufficient if we know something isn't null.
2020-09-09Temporairly revert "Thread safety analysis: Consider global variables in ↵Roman Lebedev1-1/+1
scope" & followup This appears to cause false-positives because it started to warn on local non-global variables. Repro posted to https://reviews.llvm.org/D84604#2262745 This reverts commit 9dcc82f34ea9b623d82d2577b93aaf67d36dabd2. This reverts commit b2ce79ef66157dd752e3864ece57915e23a73f5d.
2020-09-05Thread safety analysis: ValueDecl in Project is non-nullAaron Puchert1-1/+1
The constructor asserts that, use it in the ThreadSafetyAnalyzer. Also note that the result of a cast<> cannot be null.
2019-11-19[NFC] Refactor representation of materialized temporariesTyker1-2/+1
Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
2019-11-17Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber1-1/+2
This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
2019-11-16[NFC] Refactor representation of materialized temporariesTyker1-2/+1
Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
2019-03-25Thread Safety: also look at ObjC methodsJF Bastien1-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
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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
2018-12-21[AST][NFC] Pass the AST context to one of the ctor of DeclRefExpr.Bruno Ricci1-1/+2
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
2018-10-31Create ConstantExpr classBill Wendling1-0/+2
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
2018-09-21Thread safety analysis: Make printSCFG compile again [NFC]Aaron Puchert1-0/+13
Not used productively, so no observable functional change. Note that printSCFG doesn't yet work reliably, it seems to crash sometimes. llvm-svn: 342790
2018-09-19Thread safety analysis: Handle ObjCIvarRefExpr in SExprBuilder::translateAaron Puchert1-3/+18
Summary: This imitates the code for MemberExpr. Fixes PR38896. Reviewers: aaron.ballman, delesley, lukasza, rjmccall Reviewed By: delesley Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52200 llvm-svn: 342600
2018-09-19Thread safety analysis: Fix crash for function pointersAaron Puchert1-9/+11
For function pointers, the FunctionDecl of the callee is unknown, so getDirectCallee will return nullptr. We have to catch that case to avoid crashing. We assume there is no attribute then. llvm-svn: 342519
2018-05-09Remove \brief commands from doxygen comments.Adrian Prantl1-2/+2
This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-04-06Fix typos in clangAlexander Kornienko1-2/+2
Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
2018-03-13[Analysis] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-49/+50
other minor fixes (NFC). llvm-svn: 327453
2017-12-17Refactor overridden methods iteration to avoid double lookups.Benjamin Kramer1-4/+4
Convert most uses to range-for loops. No functionality change intended. llvm-svn: 320954
2017-12-14[c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith1-0/+1
Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
2017-09-06[CSA] [NFC] Move AnalysisContext.h to AnalysisDeclContext.hGeorge Karpenkov1-1/+1
The implementation is in AnalysisDeclContext.cpp and the class is called AnalysisDeclContext. Making those match up has numerous benefits, including: - Easier jump from header to/from implementation. - Easily identify filename from class. Differential Revision: https://reviews.llvm.org/D37500 llvm-svn: 312671
2016-12-03DR616, and part of P0135R1: member access (or pointer-to-member access) on aRichard Smith1-0/+3
temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
2016-07-18[NFC] Header cleanupMehdi Amini1-6/+0
Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
2015-10-27[coroutines] Creation of promise object, lookup of operator co_await, buildingRichard Smith1-0/+1
of await_* calls, and AST representation for same. llvm-svn: 251387
2015-10-06Fix Clang-tidy modernize-use-nullptr warnings in source directories; other ↵Hans Wennborg1-44/+3
minor cleanups Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13406 llvm-svn: 249484
2015-09-29Thread Safety Analysis: fix before/after checks so that they work on globalDeLesley Hutchins1-1/+1
variables as well member variables. llvm-svn: 248803
2015-08-12[modules] Fix thread safety analysis to cope with merging of FieldDecls ↵Richard Smith1-1/+2
across modules. llvm-svn: 244714
2015-03-09Hide away implementation details of the ThreadSafetyAnalysis in anonymous ↵Benjamin Kramer1-27/+11
namespaces NFC. llvm-svn: 231653
2015-01-14[cleanup] Re-sort *all* #include lines with llvm/utils/sort_includes.pyChandler Carruth1-1/+0
Sorry for the noise, I managed to miss a bunch of recent regressions of include orderings here. This should actually sort all the includes for Clang. Again, no functionality changed, this is just a mechanical cleanup that I try to run periodically to keep the #include lines as regular as possible across the project. llvm-svn: 225979
2014-09-10Thread Safety Analysis: major update to thread safety TIL.DeLesley Hutchins1-35/+30
Numerous changes, including: * Changed the way variables and instructions are handled in basic blocks to be more efficient. * Eliminated SExprRef. * Simplified futures. * Fixed documentation. * Compute dominator and post dominator trees. llvm-svn: 217556
2014-08-04Thread safety analysis: Add support for negative requirements, which areDeLesley Hutchins1-12/+35
capability expressions of the form !expr, and denote a capability that must not be held. llvm-svn: 214725
2014-07-28Thread Safety Analysis: Replace the old and broken SExpr with the newDeLesley Hutchins1-33/+215
til::SExpr. This is a large patch, with many small changes to pretty printing and expression lowering to make the new SExpr representation equivalent in functionality to the old. llvm-svn: 214089
2014-05-29Thread Safety Analysis: implement review suggestions from Aaron Ballman.DeLesley Hutchins1-1/+1
llvm-svn: 209847
2014-05-28Thread Safety Analysis: update TIL traversal mechanism to allow arbitraryDeLesley Hutchins1-7/+10
local contexts. Also includes some minor refactoring. llvm-svn: 209774