summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/LLVMUserExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-291-1/+0
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 268083
* Revert "Fixed a bug where const this would cause parser errors about ↵Pavel Labath2016-04-281-0/+1
| | | | | | | | | | $__lldb_expr." This reverts commit r267833 as it breaks the build. It looks like some work in progress got committed together with the actual fix, but I'm not sure which one is which, so I'll revert the whole patch and let author resumbit it after fixing the build error. llvm-svn: 267861
* Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-281-1/+0
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 267833
* Breakpoint conditions were making result variables, which they should not do. Jim Ingham2016-04-121-3/+3
| | | | | | | | | | | | | | The result variables aren't useful, and if you have a breakpoint on a common function you can generate a lot of these. So I changed the code that checks the condition to set ResultVariableIsInternal in the EvaluateExpressionOptions that we pass to the execution. Unfortunately, the check for this variable was done in the wrong place (the static UserExpression::Evaluate) which is not how breakpoint conditions execute expressions (UserExpression::Execute). So I moved the check to UserExpression::Execute (which Evaluate also calls) and made the overridden method DoExecute. llvm-svn: 266093
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-34/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* Fix bug with function resolution when using IR InterpreterTed Woodward2016-03-011-1/+1
| | | | | | | | | | | | Summary: Recent changes to the expression parser broke function name resolution when using the IR interpreter instead of JIT. This patch changes the IRMemoryMap ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on the name of the Value when it's a FunctionVal. It also changes IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if ResolveCallableAddress() fails and there is no valid Process. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17745 llvm-svn: 262407
* AddInitialArguments -> AddArguments, and we pass in the struct_address and ↵Jim Ingham2015-11-051-8/+4
| | | | | | | | | push it too. All the callers had to do this by hand and we ended up never actually adding initial arguments and then reusing them by passing in the struct address separately, so the distinction wasn't needed. llvm-svn: 252108
* Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. ↵Jim Ingham2015-11-041-5/+15
| | | | | | | | Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
* Add the ability to pass an EvaluateExpressionOptions when you make a ↵Jim Ingham2015-11-031-3/+7
| | | | | | | | UserExpression. This isn't used in this commit but will be in a future commit. llvm-svn: 251887
* Create an expression parser for Go.Ryan Brown2015-11-021-0/+353
The Go interpreter doesn't JIT or use LLVM, so this also moves all the JIT related code from UserExpression to a new class LLVMUserExpression. Differential Revision: http://reviews.llvm.org/D13073 Fix merge llvm-svn: 251820
OpenPOWER on IntegriCloud