summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/ExpressionVariable.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Collect IRExecutionUnits as part of persistent expression state.Sean Callanan2016-03-211-0/+54
| | | | | | | | | | | | | IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-301-0/+4
| | | | | | | | | | the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
* This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan2015-09-041-0/+21
| | | | | | | | | stores information about a variable that different parts of LLDB use, from the compiler-specific portion that only the expression parser cares about. http://reviews.llvm.org/D12602 llvm-svn: 246871
* In preparation for factoring persistent variables into a generic part and aSean Callanan2015-09-031-0/+11
Clang-specific part, create the ExpressionVariable source/header file and move ClangExpressionVariable into the Clang expression parser plugin. It is expected that there are some ugly #include paths... these will be resolved by either (1) making that code use generic expression variables (once they're separated appropriately) or (2) moving that code into a plug-in, often the expression parser plug-in. llvm-svn: 246737
OpenPOWER on IntegriCloud