summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0636-16271/+14043
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Fixed the location of a conditional to make the following code clearer.Sean Callanan2016-08-271-7/+7
| | | | llvm-svn: 279896
* The error stream in IRForTarget is never null, so use it instead of the log.Sean Callanan2016-08-273-102/+53
| | | | llvm-svn: 279894
* Fixed a bad lldbassert() condition.Sean Callanan2016-08-261-1/+1
| | | | llvm-svn: 279884
* Don't crash when trying to capture persistent variables in a block.Sean Callanan2016-08-263-8/+31
| | | | | | | | | Reports an error instead. We can fix this later to make persistent variables work, but right now we hit an LLVM assertion if we get this wrong. <rdar://problem/27770298> llvm-svn: 279850
* Fix expression evaluation with operator newPavel Labath2016-08-151-5/+2
| | | | | | | | | | | | | | | | Summary: referencing a user-defined operator new was triggering an assert in clang because we were registering the function name as string "operator new", instead of using the special operator enum, which clang has for this purpose. Method operators already had code to handle this, and now I extend this to cover free standing operator functions as well. Test included. Reviewers: spyffe Subscribers: sivachandra, paulherman, lldb-commits Differential Revision: http://reviews.llvm.org/D17856 llvm-svn: 278670
* Typo corrections identified by codespellEd Maste2016-07-191-3/+3
| | | | | | | | | Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
* Add missing headers after header cleanup in r275882.Chaoren Lin2016-07-181-0/+2
| | | | llvm-svn: 275914
* Check whether Sema::CreateBuiltinUnaryOp returns an empty result.Jim Ingham2016-07-071-0/+2
| | | | | | | | | If it does, calling AddInitializerToDecl will crash, so we should abort the result synthesis in this case. <rdar://problem/27205383> llvm-svn: 274787
* Add an "experimental" setting to disable injecting local variables into ↵Jim Ingham2016-07-071-2/+2
| | | | | | | | | | | | | | | | expressions. This feature was added to solve a lookup problem in expressions when local variables shadow ivars. That solution requires fully realizing all local variables to evaluate any expression, and can cause significant performance problems when evaluating expressions in frames that have many complex locals. Until we get a better solution, this setting mitigates the problem when you don't have local variables that shadow ivars. <rdar://problem/27226122> llvm-svn: 274783
* Fixed a bug where we report a single type multiple times in namespaces.Sean Callanan2016-07-052-6/+8
| | | | | | | | Also added a testcase. <rdar://problem/22786569> llvm-svn: 274580
* Removed the redundant "%d errors parsing expression" error. Nobody keeps score.Sean Callanan2016-06-302-5/+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
* Allow runtimes to execute custom LLVM ModulePasses over the expression IRLuke Drummond2016-06-151-1/+35
| | | | | | | | | | | | | | | | During expression evaluation, the ClangExpressionParser preforms a number of hard-coded fixups on the expression's IR before the module is assembled and dispatched to be run in a ThreadPlan. This patch allows the runtimes to register LLVM passes to be run over the generated IR, that they may perform language or architecture-specfic fixups or analyses over the generated expression. This makes expression evaluation for plugins more flexible and allows language-specific fixes to reside in their own module, rather than littering the expression evaluator itself with language-specific fixes. llvm-svn: 272800
* Removed the m_decl_objects map from ClangASTContext.Sean Callanan2016-05-231-1/+10
| | | | | | | | | | | | | m_decl_objects is problematic because it assumes that each VarDecl has a unique variable associated with it. This is not the case in inline contexts. Also the information in this map can be reconstructed very easily without maintaining the map. The rest of the testsuite passes with this cange, and I've added a testcase covering the inline contexts affected by this. <rdar://problem/26278502> llvm-svn: 270474
* Fixed a crash if a FunctionDecl couldn't be imported.Sean Callanan2016-05-191-3/+6
| | | | llvm-svn: 270097
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-2/+2
| | | | llvm-svn: 270024
* [LLDB] Adding lldb_private namespace to DiagnosticSeverity. NFC.Renato Golin2016-05-141-1/+1
| | | | | | | | This is a fix due to the addition of the new DiagnosticSeverity in LLVMContext.h. This may warrant a change in name to be LLDB specific but I leave that to the LLDB experts to refactor. llvm-svn: 269562
* Remove unused variableEd Maste2016-05-131-2/+1
| | | | llvm-svn: 269421
* [LLDB][MIPS] Provide ABI string to compiler for appropriate code generation ↵Sagar Thakur2016-05-132-2/+43
| | | | | | | | | | | | | for MIPS Patch by Nitesh Jain. Summary: These patch will set clang::TargetOptions::ABI and accordingly code will be generated for MIPS target. Reviewers: ovyalov, clayborg Subscribers: lldb-commits, mohit.bhakkad, sagar, jaydeep, bhushan Differential: D18638 llvm-svn: 269407
* [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-292-5/+15
| | | | | | | | | | | | | | | | | | | 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-282-15/+5
| | | | | | | | | | $__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
* Fix an inefficiency in the handling of $__lldb_local_vars in expressions.Jim Ingham2016-04-282-1/+3
| | | | | | | | | | | | | | The code in ClangExpressionDeclMap::FindExternalVisibleDecls figures out what the token means, and adds the namespace to the lookup context, but since it doesn't mark it as special in the search context, we go on to pass the name $__lldb_local_vars to the ASTSource for further lookup. Unless we've done our job wrong, those lookups will always fail, but the can be costly. So I added a bit to m_found & use that to short-circuit the lookup. <rdar://problem/25613384> llvm-svn: 267842
* Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-282-5/+15
| | | | | | | | | | | | | | | | | | | 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
* Expressions can run without a process.Jim Ingham2016-04-211-17/+30
| | | | | | | | | | | Code was added in ClangExpressionParser::ClangExpressionParser that was calling through the process w/o checking that it was good. Also, we were pretending that we could do something reasonable if we had no target, but that's actually not true, so I check for a target at the beginning of the constructor and don't make a compiler in that case. <rdar://problem/25841198> llvm-svn: 266944
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-151-1/+7
| | | | | | | | | | | | | Recommit modified version of r266311 including build bot regression fix. This differs from the original r266311 by: - Fixing Scalar::Promote to correctly zero- or sign-extend value depending on signedness of the *source* type, not the target type. - Omitting a few stand-alone fixes that were already committed separately. llvm-svn: 266422
* Revert r266311 - Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-7/+1
| | | | | | Try to get 32-bit build bots running again. llvm-svn: 266341
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scalar implementation and a few other places in LLDB directly access the internal implementation of APInt values using the getRawData method. Unfortunately, pretty much all of these places do not handle big-endian systems correctly. While on little-endian machines, the pointer returned by getRawData can simply be used as a pointer to the integer value in its natural format, no matter what size, this is not true on big-endian systems: getRawData actually points to an array of type uint64_t, with the first element of the array always containing the least-significant word of the integer. This means that if the bitsize of that integer is smaller than 64, we need to add an offset to the pointer returned by getRawData in order to access the value in its natural type, and if the bitsize is *larger* than 64, we actually have to swap the constituent words before we can access the value in its natural type. This patch fixes every incorrect use of getRawData in the code base. For the most part, this is done by simply removing uses of getRawData in the first place, and using other APInt member functions to operate on the integer data. This can be done in many member functions of Scalar itself, as well as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter, I've had to add a Scalar::MakeUnsigned routine to parallel the existing Scalar::MakeSigned, e.g. in order to implement an unsigned divide. The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong were already unused and can be simply removed. I've also removed the Scalar::GetRawBits64 function and its few users. The one remaining user of getRawData in Scalar.cpp is GetBytes. I've implemented all the cases described above to correctly implement access to the underlying integer data on big-endian systems. GetData now simply calls GetBytes instead of reimplementing its contents. Finally, two places in the clang interface code were also accessing APInt.getRawData in order to actually construct a byte representation of an integer. I've changed those to make use of a Scalar instead, to avoid having to re-implement the logic there. The patch also adds a couple of unit tests verifying correct operation of the GetBytes routine as well as the conversion routines. Those tests actually exposed more problems in the Scalar code: the SetValueFromData routine didn't work correctly for 128- and 256-bit data types, and the SChar routine should have an explicit "signed char" return type to work correctly on platforms where char defaults to unsigned. Differential Revision: http://reviews.llvm.org/D18981 llvm-svn: 266311
* Breakpoint conditions were making result variables, which they should not do. Jim Ingham2016-04-122-8/+9
| | | | | | | | | | | | | | 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
* The FixItList typedef should have been inside "class ClangDiagnostic".Jim Ingham2016-04-061-1/+2
| | | | llvm-svn: 265496
* Fix a crasher that could happen if ClangASTSource::CompleteType() found a ↵Greg Clayton2016-04-051-3/+3
| | | | | | | | type whose name matched, but came from a different language. We need to verify that any types we find are clang types before trying to extra a clang::QualType and then use it. <rdar://problem/24138711> llvm-svn: 265443
* Fix header name.Jim Ingham2016-03-301-1/+1
| | | | llvm-svn: 264883
* Fix warning in ClangExpressionParserPavel Labath2016-03-301-1/+1
| | | | llvm-svn: 264847
* 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
* Move some functions from DWARFASTParserClang to ClangASTImporter.Zachary Turner2016-03-283-22/+17
| | | | | | | | | | | | | | | | | | This allows these functions to be re-used by a forthcoming PDBASTParser. The functions in question are CanCompleteType, CompleteType, and CanImport. Conceptually, these functions belong on ClangASTImporter anyway, and previously they were just ping ponging around through a few levels of indirection to end up there as well, so this patch actually makes the code somewhat simpler. A few methods were moved to a new file called ClangUtil, so that they can be shared between ClangASTImporter and ClangASTContext without creating a circular dependency between those two cpp files. Differential Revision: http://reviews.llvm.org/D18381 llvm-svn: 264685
* Removed an override of LookupSymbol that mistakenly disabled it for Clang.Sean Callanan2016-03-281-3/+0
| | | | llvm-svn: 264659
* 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
* Removed LoggingDiagnosticConsumer, an unused class.Sean Callanan2016-03-251-50/+0
| | | | llvm-svn: 264478
* Fix now-ambiguous references to Error.Lang Hames2016-03-251-5/+5
| | | | llvm-svn: 264449
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-254-12/+215
| | | | | | | | | | | | | | | "." 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
* Ignore global constructor warning in clang.Greg Clayton2016-03-241-0/+4
| | | | llvm-svn: 264361
* Backend support for top-level Clang epxressionsSean Callanan2016-03-228-210/+372
| | | | | | | | | | | | | | | | | | 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
* Collect IRExecutionUnits as part of persistent expression state.Sean Callanan2016-03-212-0/+115
| | | | | | | | | | | | | 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
* Compilation can end up calling functions (e.g. to resolve indirect ↵Jim Ingham2016-03-212-2/+13
| | | | | | | | | | functions) so I added a way for compilation to take a "thread to use for compilation". If it isn't set then the compilation will use the currently selected thread. This should help keep function execution to the one thread intended. llvm-svn: 263972
* Handle any persistent Decl in the Clang expression parser, not just types.Sean Callanan2016-03-194-55/+82
| | | | | | | | | | Persistent decls have traditionally only been types. However, we want to be able to persist more things, like functions and global variables. This changes some of the nomenclature and the lookup rules to make this possible. <rdar://problem/22864976> llvm-svn: 263864
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-1910-144/+221
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Track expression language from one place in ClangExpressionParser"Ewan Crawford2016-03-102-9/+9
| | | | | | r263099 seems to have broken some OSX tests llvm-svn: 263107
* Track expression language from one place in ClangExpressionParserEwan Crawford2016-03-102-9/+9
| | | | | | | | | | The current expression language is currently tracked in a few places within the ClangExpressionParser constructor. This patch adds a private lldb::LanguageType attribute to the ClangExpressionParser class and tracks the expression language from that one place. Author: Luke Drummond <luke.drummond@codeplay.com> Differential Revision: http://reviews.llvm.org/D17719 llvm-svn: 263099
* Update after r262737 in clang changed the accessor.James Y Knight2016-03-041-1/+1
| | | | llvm-svn: 262739
* remove unused local string in IRForTarget.cppAidan Dodds2016-02-261-2/+0
| | | | | | | | Committed on behalf of: ldrumm <luke.drummond@codeplay.com> Differential revision: http://reviews.llvm.org/D16412 llvm-svn: 262043
OpenPOWER on IntegriCloud