summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Move classes from Core -> Utility.Zachary Turner2017-02-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Make DiagnosticsManager functions take StringRefs.Zachary Turner2016-11-121-14/+14
| | | | llvm-svn: 286730
* Convert some Expression parser functions to StringRef.Zachary Turner2016-11-081-4/+4
| | | | llvm-svn: 286208
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-568/+525
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Removed the redundant "%d errors parsing expression" error. Nobody keeps score.Sean Callanan2016-06-301-2/+0
| | | | | | <rdar://problem/24306284> llvm-svn: 274254
* Don't omit `this' from expression args if it couldn't be read, but warn loudly.Sean Callanan2016-06-221-5/+4
| | | | | | <rdar://problem/26935520> llvm-svn: 273445
* [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-291-1/+1
| | | | | | | | | | | | | | | | | | | 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-1/+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/+1
| | | | | | | | | | | | | | | | | | | 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
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-291-33/+21
| | | | | | | | | | | | | setting to quietly apply fixits for those who really trust clang's fixits. Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present. <rdar://problem/25351938> llvm-svn: 264793
* Record all translation units with more than one function in them (e.g., blocks).Sean Callanan2016-03-261-3/+9
| | | | | | | | | | | Blocks and lambdas have their implementation functions stored in the IR for an expression. If we put the block/lambda into a result variable it needs to stay around. As a heuristic, remember any execution unit that has more than one function in it. <rdar://problem/22864976> llvm-svn: 264483
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-251-7/+38
| | | | | | | | | | | | | | | "." for "->".) This feature is controlled by an expression command option, a target property and the SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions, those you have to get right when you make them. This is just a first stage. At present the fixits are applied silently. The next step is to tell the user about the applied fixit. <rdar://problem/25351938> llvm-svn: 264379
* Backend support for top-level Clang epxressionsSean Callanan2016-03-221-74/+109
| | | | | | | | | | | | | | | | | | This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which tells the expression parser that the expression should be JITted as top level code but nothing (except static initializers) should be run. I have modified the Clang expression parser to recognize this execution policy. On top of the existing patches that support storing IR and maintaining a map of arbitrary Decls, this is mainly just patching up a few places in the expression parser. I intend to submit a patch for review that exposes this functionality through the "expression" command and through the SB API. That patch also includes a testcase for all of this. <rdar://problem/22864976> llvm-svn: 264095
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-24/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* AddInitialArguments -> AddArguments, and we pass in the struct_address and ↵Jim Ingham2015-11-051-4/+9
| | | | | | | | | 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 the ability to pass an EvaluateExpressionOptions when you make a ↵Jim Ingham2015-11-031-4/+8
| | | | | | | | 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-7/+4
| | | | | | | | | | | 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
* Add PersistentVariableDelegate to handle language-specific dematerialization.Sean Callanan2015-10-031-3/+55
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Made Target hold a map of languages to TypeSystems, and added some accessors.Sean Callanan2015-10-011-1/+1
| | | | | | | | 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
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-301-1/+1
| | | | | | | | | | 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 more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-0/+615
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
OpenPOWER on IntegriCloud