summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-215-94/+91
| | | | | | | | source/Plugins; other minor fixes. Differential Revision: http://reviews.llvm.org/D13916 llvm-svn: 250872
* Reduce header inclusion in Expression.Bruce Mitchener2015-10-074-4/+2
| | | | | | | | | | Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13333 llvm-svn: 249570
* Add PersistentVariableDelegate to handle language-specific dematerialization.Sean Callanan2015-10-035-11/+95
| | | | | | | | | | | | | | | | | | | | | | | | The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
* Eliminated redundant "constructors" for ClangExpressionVariable. ↵Sean Callanan2015-10-015-75/+58
| | | | | | | | | | | | | The ClangExpressionVariable::CreateVariableInList functions looked cute, but caused more confusion than they solved. I removed them, and instead made sure that there are adequate facilities for easily adding newly-constructed ExpressionVariables to lists. I also made some of the constructors that are common be generic, so that it's possible to construct expression variables from generic places (like the ABI and ValueObject) without having to know the specifics about the class. llvm-svn: 249095
* Made Target hold a map of languages to TypeSystems, and added some accessors.Sean Callanan2015-10-014-4/+4
| | | | | | | | Also added some target-level search functions so that persistent variables and symbols can be searched for without hand-iterating across the map of TypeSystems. llvm-svn: 249027
* Changed PersistentExpressionState to allow symbol lookups. Clang doesn'tSean Callanan2015-10-011-0/+3
| | | | | | report any (yet). llvm-svn: 248970
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-306-8/+21
| | | | | | | | | | 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
* Moved ClangExpressionHelper.h into the Clang expression parser plug-in.Sean Callanan2015-09-253-2/+82
| | | | llvm-svn: 248631
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-2525-0/+13745
| | | | | | | | | There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
* ExpressionVariable now uses llvm::cast() instead of As...() for RTTI.Sean Callanan2015-09-082-10/+15
| | | | | | | | As part of our overall switch from hand-rolling RTTI to using LLVM-compatible methods, I've done the same for ExpressionVariable. The main documentation for how to do this is in TypeSystem.h, so I've simply referred to that. llvm-svn: 247085
* Fix Makefile buildKeno Fischer2015-09-051-0/+14
| | | | llvm-svn: 246932
* This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan2015-09-042-338/+86
| | | | | | | | | 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
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Fix cmake build.Bruce Mitchener2015-09-032-0/+6
| | | | llvm-svn: 246746
* In preparation for factoring persistent variables into a generic part and aSean Callanan2015-09-032-0/+601
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