aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Analysis/AnalysisDeclContext.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-05-31[Analysis] Remove unused includes (NFC) (#142255)Kazu Hirata1-2/+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-02-24[analyzer] Clean up slightly the messed up ownership model of the analyzer ↵Balazs Benics1-2/+2
(#128368) Well, yes. It's not pretty. At least after this we would have a bit more unique pointers than before. This is for fixing the memory leak diagnosed by: https://lab.llvm.org/buildbot/#/builders/24/builds/5580 And that caused the revert of #127409. After these uptrs that patch can re-land finally.
2022-12-02Use CTAD on llvm::SaveAndRestoreJan Svoboda1-2/+1
Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D139229
2022-08-04[Clang][C++20] Support capturing structured bindings in lambdasCorentin Jabot1-3/+3
This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-08-03Revert "[Clang][C++20] Support capturing structured bindings in lambdas"Corentin Jabot1-3/+3
This reverts commit 44f2baa3804a62ca793f0ff3e43aa71cea91a795. Breaks self builds and seems to have conformance issues.
2022-08-03[Clang][C++20] Support capturing structured bindings in lambdasCorentin Jabot1-3/+3
This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-04-20[clang] Add a raw_ostream operator<< overload for QualTypeNathan James1-1/+1
Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostream. Also cleaned up all the call sites where this occurs. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D123926
2021-12-09[NFC][analyzer] Return underlying strings directly instead of OS.str()Logan Smith1-1/+1
This avoids an unnecessary copy required by 'return OS.str()', allowing instead for NRVO or implicit move. The .str() call (which flushes the stream) is no longer required since 65b13610a5226b84889b923bae884ba395ad084d, which made raw_string_ostream unbuffered by default. Differential Revision: https://reviews.llvm.org/D115374
2021-07-12[analyzer][NFC] Display the correct function name even in crash dumpsBalazs Benics1-1/+54
The `-analyzer-display-progress` displayed the function name of the currently analyzed function. It differs in C and C++. In C++, it prints the argument types as well in a comma-separated list. While in C, only the function name is displayed, without the brackets. E.g.: C++: foo(), foo(int, float) C: foo In crash traces, the analyzer dumps the location contexts, but the string is not enough for `-analyze-function` in C++ mode. This patch addresses the issue by dumping the proper function names even in stack traces. Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D105708
2020-04-28AnalysisDeclContext::ManagedAnalyses: Use unique_ptr to simplify memory ↵David Blaikie1-8/+3
management
2020-03-04[analyzer] AnalysisDeclContext: Refactor and documentationCharusso1-74/+32
Summary: `ScopeContext` wanted to be a thing, but sadly it is dead code. If you wish to continue the work in D19979, here was a tiny code which could be reused, but that tiny and that dead, I felt that it is unneded. Note: Other changes are truly uninteresting. Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D73519
2019-08-14[Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-1/+1
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
2019-08-01[analyzer] StackFrameContext: Add NodeBuilderContext::blockCount() to its ↵Csaba Dabis1-10/+11
profile Summary: It allows discriminating between stack frames of the same call that is called multiple times in a loop. Thanks to Artem Dergachev for the great idea! Reviewed By: NoQ Tags: #clang Differential Revision: https://reviews.llvm.org/D65587 llvm-svn: 367608
2019-07-12[analyzer] exploded-graph-rewriter: Improve source location dumps.Artem Dergachev1-6/+4
- Correctly display macro expansion and spelling locations. - Use the same procedure to display location context call site locations. - Display statement IDs for program points. llvm-svn: 365861
2019-06-19[analyzer] Fix JSON dumps for location contexts.Artem Dergachev1-2/+3
Location context ID is a property of the location context, not of an item within it. It's useful to know the id even when there are no items in the context, eg. for the purposes of figuring out how did contents of the Environment for the same location context changed across states. Differential Revision: https://reviews.llvm.org/D62754 llvm-svn: 363895
2019-05-29[analyzer] print() JSONify: Environment implementationCsaba Dabis1-20/+75
Summary: - Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus Reviewed By: NoQ Subscribers: szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D62081 llvm-svn: 361976
2019-05-24[CFG] Add branch to skip vbase inits when they're handled by superclass.Artem Dergachev1-1/+2
This patch adds the run-time CFG branch that would skip initialization of virtual base classes depending on whether the constructor is called from a superclass constructor or not. Previously the Static Analyzer was already skipping virtual base-class initializers in such constructors, but it wasn't skipping their arguments and their potential side effects, which was causing pr41300 (and was generally incorrect). The previous skipping behavior is now replaced with a hard assertion that we're not even getting there due to how our CFG works. The new CFG element is under a CFG build option so that not to break other consumers of the CFG by this change. Static Analyzer support for this change is implemented. Differential Revision: https://reviews.llvm.org/D61816 llvm-svn: 361681
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-09-15[analyzer] Generate and use stable identifiers for LocationContextGeorge Karpenkov1-3/+3
Those are not created in the allocator. Since they are created fairly rarely, a counter overhead should not affect the memory consumption. Differential Revision: https://reviews.llvm.org/D51827 llvm-svn: 342314
2018-09-14Remove PseudoConstantAnalysisShuai Wang1-7/+0
Summary: It's not used anywhere for years. The last usage is removed in https://reviews.llvm.org/rL198476 in 2014. Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D51946 llvm-svn: 342246
2018-08-09Port getLocStart -> getBeginLocStephen Kelly1-3/+3
Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
2018-07-30Remove trailing spaceFangrui Song1-9/+9
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-06-28[CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision.Artem Dergachev1-1/+3
Before C++17 copy elision was optional, even if the elidable copy/move constructor had arbitrary side effects. The elidable constructor is present in the AST, but marked as elidable. In these cases CFG now contains additional information that allows its clients to figure out if a temporary object is only being constructed so that to pass it to an elidable constructor. If so, it includes a reference to the elidable constructor's construction context, so that the client could elide the elidable constructor and construct the object directly at its final destination. Differential Revision: https://reviews.llvm.org/D47616 llvm-svn: 335795
2018-06-27[analyzer] [NFC] A convenient getter for getting a current stack frameGeorge Karpenkov1-2/+2
Differential Revision: https://reviews.llvm.org/D44756 llvm-svn: 335701
2018-03-21[Analysis] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-56/+58
other minor fixes (NFC). llvm-svn: 328063
2018-03-12[analyzer] Add scope information to CFGMaxim Ostapenko1-3/+4
This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate when a local scope begins and ends respectively. We use first VarDecl declared in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements into corresponding basic blocks. Differential Revision: https://reviews.llvm.org/D16403 llvm-svn: 327258
2018-02-08[CFG] Add extra context to C++ constructor statement elements.Artem Dergachev1-1/+3
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
2018-02-08[analyzer] Self-debug: Dump environment frame-by-frame.Artem Dergachev1-8/+34
It makes it easier to discriminate between values of similar expressions in different stack frames. It also makes the separate backtrace section in ExplodedGraph dumps redundant. Differential Revision: https://reviews.llvm.org/D42552 llvm-svn: 324660
2017-11-01[analyzer] Removing unused stored field.George Karpenkov1-1/+1
llvm-svn: 317070
2017-11-01[Analyzer] Use value storage for BodyFarmGeorge Karpenkov1-8/+5
Differential Revision: https://reviews.llvm.org/D39428 llvm-svn: 317065
2017-10-25[Analyzer] Give more descriptive name to BdyFrm field.George Karpenkov1-3/+3
Discussion at: https://reviews.llvm.org/D39220 llvm-svn: 316617
2017-10-24[Analyzer] Store BodyFarm in std::unique_ptrGeorge Karpenkov1-7/+2
Differential Revision: https://reviews.llvm.org/D39220 llvm-svn: 316536
2017-10-24[Analyzer] Fix for the memory leak: fix typo in if-statement.George Karpenkov1-1/+1
llvm-svn: 316403
2017-10-23[Analyzer] Do not use static storage to for implementations created in ↵George Karpenkov1-23/+19
BodyFarm.cpp Differential Revision: https://reviews.llvm.org/D39208 llvm-svn: 316400
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
2017-08-19[CFG] Add LoopExit information to CFGPeter Szecsi1-0/+2
This patch introduces a new CFG element CFGLoopExit that indicate when a loop ends. It does not deal with returnStmts yet (left it as a TODO). It hidden behind a new analyzer-config flag called cfg-loopexit (false by default). Test cases added. The main purpose of this patch right know is to make loop unrolling and loop widening easier and more efficient. However, this information can be useful for future improvements in the StaticAnalyzer core too. Differential Revision: https://reviews.llvm.org/D35668 llvm-svn: 311235
2017-07-12CFG: Add CFGElement for automatic variables that leave the scopeMatthias Gehre1-0/+2
Summary: This mimics the implementation for the implicit destructors. The generation of this scope leaving elements is hidden behind a flag to the CFGBuilder, thus it should not affect existing code. Currently, I'm missing a test (it's implicitly tested by the clang-tidy lifetime checker that I'm proposing). I though about a test using debug.DumpCFG, but then I would have to add an option to StaticAnalyzer/Core/AnalyzerOptions to enable the scope leaving CFGElement, which would only be useful to that particular test. Any other ideas how I could make a test for this feature? Reviewers: krememek, jordan_rose Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15031 llvm-svn: 307759
2017-05-25[coroutines] Fix fallthrough diagnostics for coroutinesEric Fiselier1-0/+2
Summary: This patch fixes a number of issues with the analysis warnings emitted when a coroutine may reach the end of the function w/o returning. * Fix bug where coroutines with `return_value` are incorrectly diagnosed as missing `co_return`'s. * Rework diagnostic message to no longer say "non-void coroutine", because that implies the coroutine doesn't have a void return type, which it might. In this case a non-void coroutine is one who's promise type does not contain `return_void()` As a side-effect of this patch, coroutine bodies that contain an invalid coroutine promise objects are marked as invalid. Reviewers: GorNishanov, rsmith, aaron.ballman, majnemer Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33532 llvm-svn: 303831
2016-10-10[Analysis] Use unique_ptr in AnalyaisDeclContextManager's ContextMap.Justin Lebar1-9/+5
Reviewers: timshen Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25426 llvm-svn: 283774
2016-03-28[analyzer] Use BodyFarm-synthesized body even when actual body available.Devin Coughlin1-6/+12
Change body autosynthesis to use the BodyFarm-synthesized body even when an actual body exists. This enables the analyzer to use the simpler, analyzer-provided body to model the behavior of the function rather than trying to understand the actual body. Further, this makes the analyzer robust against changes in headers that expose the implementations of those bodies. rdar://problem/25145950 llvm-svn: 264687
2016-02-23[analyzer] Find ObjC 'self' decl even when block captures local named 'self'.Devin Coughlin1-2/+6
When looking up the 'self' decl in block captures, make sure to find the actual self declaration even when the block captures a local variable named 'self'. rdar://problem/24751280 llvm-svn: 261703
2016-02-07[analyzer] Invalidate destination of std::copy() and std::copy_backward().Devin Coughlin1-0/+15
Now that the libcpp implementations of these methods has a branch that doesn't call memmove(), the analyzer needs to invalidate the destination for these methods explicitly. rdar://problem/23575656 llvm-svn: 260043
2015-11-15[analyzer] Handle calling ObjC super method from inside C++ lambda.Devin Coughlin1-0/+17
When calling a ObjC method on super from inside a C++ lambda, look at the captures to find "self". This mirrors how the analyzer handles calling super in an ObjC block and fixes an assertion failure. rdar://problem/23550077 llvm-svn: 253176
2015-10-20Roll-back r250822.Angel Garcia Gomez1-2/+2
Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
2015-10-20Apply modernize-use-default to clang.Angel Garcia Gomez1-2/+2
Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: bkramer, klimek Subscribers: klimek, alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13890 llvm-svn: 250822
2015-07-02Switch users of the 'for (StmtRange range = stmt->children(); range; ↵Benjamin Kramer1-3/+3
++range)‘ pattern to range for loops. The pattern was born out of the lack of range-based for loops in C++98 and is somewhat obscure. No functionality change intended. llvm-svn: 241300
2015-02-06Update APIs that return a pair of iterators to return an iterator_range instead.Benjamin Kramer1-4/+4
Convert uses of those APIs into ranged for loops. NFC. llvm-svn: 228404
2014-11-19Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie1-1/+1
pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
2014-08-29unique_ptrify the result of CFG::buildCFG/CFGBuilder::buildCFGDavid Blaikie1-4/+3
llvm-svn: 216755
2014-08-27Add support for the static analyzer to synthesize function implementations ↵Ted Kremenek1-6/+14
from external model files. Currently the analyzer lazily models some functions using 'BodyFarm', which constructs a fake function implementation that the analyzer can simulate that approximates the semantics of the function when it is called. BodyFarm does this by constructing the AST for such definitions on-the-fly. One strength of BodyFarm is that all symbols and types referenced by synthesized function bodies are contextual adapted to the containing translation unit. The downside is that these ASTs are hardcoded in Clang's own source code. A more scalable model is to allow these models to be defined as source code in separate "model" files and have the analyzer use those definitions lazily when a function body is needed. Among other things, it will allow more customization of the analyzer for specific APIs and platforms. This patch provides the initial infrastructure for this feature. It extends BodyFarm to use an abstract API 'CodeInjector' that can be used to synthesize function bodies. That 'CodeInjector' is implemented using a new 'ModelInjector' in libFrontend, which lazily parses a model file and injects the ASTs into the current translation unit. Models are currently found by specifying a 'model-path' as an analyzer option; if no path is specified the CodeInjector is not used, thus defaulting to the current behavior in the analyzer. Models currently contain a single function definition, and can be found by finding the file <function name>.model. This is an initial starting point for something more rich, but it bootstraps this feature for future evolution. This patch was contributed by Gábor Horváth as part of his Google Summer of Code project. Some notes: - This introduces the notion of a "model file" into FrontendAction and the Preprocessor. This nomenclature is specific to the static analyzer, but possibly could be generalized. Essentially these are sources pulled in exogenously from the principal translation. Preprocessor gets a 'InitializeForModelFile' and 'FinalizeForModelFile' which could possibly be hoisted out of Preprocessor if Preprocessor exposed a new API to change the PragmaHandlers and some other internal pieces. This can be revisited. FrontendAction gets a 'isModelParsingAction()' predicate function used to allow a new FrontendAction to recycle the Preprocessor and ASTContext. This name could probably be made something more general (i.e., not tied to 'model files') at the expense of losing the intent of why it exists. This can be revisited. - This is a moderate sized patch; it has gone through some amount of offline code review. Most of the changes to the non-analyzer parts are fairly small, and would make little sense without the analyzer changes. - Most of the analyzer changes are plumbing, with the interesting behavior being introduced by ModelInjector.cpp and ModelConsumer.cpp. - The new functionality introduced by this change is off-by-default. It requires an analyzer config option to enable. llvm-svn: 216550