aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Expression/ExpressionSourceCode.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone1-324/+281
*** 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
2016-07-07Add an "experimental" setting to disable injecting local variables into ↵Jim Ingham1-3/+7
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
2016-04-29[fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan1-3/+2
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
2016-04-28Revert "Fixed a bug where const this would cause parser errors about ↵Pavel Labath1-2/+3
$__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
2016-04-28Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan1-3/+2
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
2016-04-26When building the list of variables we're going to write "using ↵Jim Ingham1-1/+1
$_lldb_local_vars" statements for, be sure not to include variables that have no locations. We wouldn't be able to realize them, and that will cause all expressions to fail. llvm-svn: 267500
2016-04-06Don't write "using $_lldb_local_vars" statements for variables withJim Ingham1-1/+1
no name. These were showing up with a recent clang, I haven't tracked down why yet, but adding them is clearly wrong. llvm-svn: 265494
2016-03-29Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham1-8/+59
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
2016-02-05Take 2: Use an artifical namespace so that member vars do not hide local vars.Siva Chandra1-2/+31
Summary: This relands r259810 with fix for failures on Mac. Reviewers: spyffe, tfiala Subscribers: tfiala, lldb-commits Differential Revision: http://reviews.llvm.org/D16900 llvm-svn: 259902
2016-02-04Revert "Use an artifical namespace so that member vars do not hide local vars."Siva Chandra1-31/+2
Summary: This reverts commit 8af14b5f9af68c31ac80945e5b5d56f0a14b38e4. Reverting as it breaks a few tests on Mac. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16895 llvm-svn: 259823
2016-02-04Use an artifical namespace so that member vars do not hide local vars.Siva Chandra1-2/+31
Summary: While evaluating expressions when stopped in a class method, there was a problem of member variables hiding local variables. This was happening because, in the context of a method, clang already knew about member variables with their name and assumed that they were the only variables with those names in scope. Consequently, clang never checks with LLDB about the possibility of local variables with the same name and goes wrong. This change addresses the problem by using an artificial namespace "$__lldb_local_vars". All local variables in scope are declared in the "$__lldb_expr" method as follows: using $__lldb_local_vars::<local var 1>; using $__lldb_local_vars::<local var 2>; ... This hides the member variables with the same name and forces clang to enquire about the variables which it thinks are declared in $__lldb_local_vars. When LLDB notices that clang is enquiring about variables in $__lldb_local_vars, it looks up local vars and conveys their information if found. This way, member variables do not hide local variables, leading to correct evaluation of expressions. A point to keep in mind is that the above solution does not solve the problem for one specific case: namespace N { int a; } class A { public: void Method(); int a; }; void A::Method() { using N::a; ... // Since the above solution only touches locals, it does not // force clang to enquire about "a" coming from namespace N. } Reviewers: clayborg, spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16746 llvm-svn: 259810
2016-01-26Revert r258546.Saleem Abdulrasool1-1/+0
Seems that the patch was rebased on top of another change which obsoleted the change but wasnt caught. Thanks to nbjoerg for pointing this out! llvm-svn: 258821
2016-01-22Silence -Wreturn-type warningsSaleem Abdulrasool1-0/+1
Address a couple of instances of -Wreturn-type warning from GCC. The switches are covered, add an llvm_unreachable to the end of the functions to silence the warning. NFC. llvm-svn: 258546
2016-01-19Placate MVSC after my last commit.Davide Italiano1-2/+2
Zachary introduced the 'default' case explicitly to placate a warning in the Microsoft compiler but that broke clang with -Werror. The new code should keep both compilers happy. llvm-svn: 258212
2016-01-19[Process] Remove dead code. All the switch cases are already covered.Davide Italiano1-2/+0
llvm-svn: 258199
2016-01-13Fix some compiler warnings with MSVC 2015.Zachary Turner1-0/+2
llvm-svn: 257671
2015-12-16Read macro info from .debug_macro section and use it for expression evaluation.Siva Chandra1-1/+136
Summary: DWARF 5 proposes a reinvented .debug_macro section. This change follows that spec. Currently, only GCC produces the .debug_macro section and hence the added test is annottated with expectedFailureClang. Reviewers: spyffe, clayborg, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15437 llvm-svn: 255729
2015-10-02Made GetScratchTypeSystemForLanguage return an error if desired.Sean Callanan1-1/+1
Also made it not store nullptrs in its TypeSystemMap, so it will retry to make the AST context if it errored out last time. llvm-svn: 249167
2015-09-30Now persistent expression data no longer lives with the Target, but rather withSean Callanan1-1/+3
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
2015-09-25Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan1-2/+2
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
2015-04-30Made macros from modules be injected before ourSean Callanan1-34/+64
global convenience expression prefix. Also ensured that if macros are defined by the modules we don't try to redefine them. Finally cleaned up a bit of code while I was in there. <rdar://problem/20756642> llvm-svn: 236266
2015-01-22Update ExpressionSourceCode::GetText() to match theJason Molenda1-1/+1
name of the iOS simulator platform which was changed in r181631. <rdar://problem/19200084> llvm-svn: 226789
2015-01-21Expression evaluation for functions with unknown signatures on works byKate Stone1-0/+4
inferring the function signature. This works well where the ABI doesn't distinguish between variadic and fixed argument lists, but on arm64 the calling conventions differ. The default assumption works for fixed argument lists, but variadic functions require explicit prototypes to be called. By far the most common case where this is an issue is when attempting to use printf(). This change augments the default expression prefix to include a working variadic prototype for the function. <rdar://problem/19024779> llvm-svn: 226744
2014-07-29Attempt to fix the expression parser after r214119Reid Kleckner1-10/+10
__INT?_TYPE__ is now explicitly, so adding an explicit 'signed' specifier causes errors. llvm-svn: 214233
2014-07-23Update lldb to track recent Triple arm64 enum removal and collapse into aarch64.Todd Fiala1-1/+1
See the following llvm change for details: r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines AArch64: remove arm64 triple enumerator. This change fixes build breaks on Linux and MacOSX lldb. llvm-svn: 213755
2014-03-29lldb arm64 import.Jason Molenda1-2/+33
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda. It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something. In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS. llvm-svn: 205113
2013-07-03Import the builtin type prefix before we import the user expression prefix ↵Greg Clayton1-4/+4
so that the user expression prefix can use the uint, int, size_t, and other types without having to define them. llvm-svn: 185488
2013-02-13Centralized the expression prefixes that are used for both expressions and ↵Greg Clayton1-29/+31
utility functions. llvm-svn: 175108
2013-02-13Made NULL, nil, and Nil use the appropriateSean Callanan1-3/+3
builtins. <rdar://problem/13204027> llvm-svn: 175091
2013-02-01Correct the definition of ObjC's BOOL in our pre-canned set of defines. ↵Jim Ingham1-1/+1
It's supposed to be "signed char" not "int". <rdar://problem/13131126> llvm-svn: 174209
2013-01-29<rdar://problem/13107904>Greg Clayton1-1/+0
wchar_t causes problem with certain compilers. Removing it for now. llvm-svn: 173823
2013-01-29Fixed a "wchar_t" typo.Greg Clayton1-2/+2
llvm-svn: 173731
2013-01-28Always define types from stdint.h so they are always available for use in ↵Greg Clayton1-12/+26
expressions no matter what debug info you have. Types added are: int8_t uint8_t int16_t uint16_t int32_t uint32_t int64_t uint64_t intptr_t uintptr_t size_t ptrdiff_t whar_t llvm-svn: 173724
2012-09-13Fixed the #defines for YES and NO, and centralizedSean Callanan1-33/+35
them in one place rather than having them replicated across all the potential function wrappers. <rdar://problem/12293880> llvm-svn: 163857
2012-05-31Made nil resolve as (id)0 and not be looked upSean Callanan1-0/+8
(which regularly conflicts with existing symbols in Objective-C). llvm-svn: 157758
2012-05-09Added a #define of NULL to 0 to make NULL usableSean Callanan1-1/+9
in expressions. llvm-svn: 156514
2011-11-15Pulled in a new version of LLVM/Clang to solve a varietySean Callanan1-16/+37
of problems with Objective-C object completion. To go along with the LLVM/Clang-side fixes, we have a variety of Objective-C improvements. Fixes include: - It is now possible to run expressions when stopped in an Objective-C class method and have "self" act just like "self" would act in the class method itself (i.e., [self classMethod] works without casting the return type if debug info is present). To accomplish this, the expression masquerades as a class method added by a category. - Objective-C objects can now provide methods and properties and methods to Clang on demand (i.e., the ASTImporter sets hasExternalVisibleDecls on Objective-C interface objects). - Objective-C built-in types, which had long been a bone of contention (should we be using "id"? "id*"?), are now fetched correctly using accessor functions on ClangASTContext. We inhibit searches for them in the debug information. There are also a variety of logging fixes, and I made two changes to the test suite: - Enabled a test case for Objective-C properties in the current translation unit. - Added a test case for calling Objective-C class methods when stopped in a class method. llvm-svn: 144607
2011-09-26Factored out handling of the source code for anSean Callanan1-0/+88
expression into a separate class. This class encapsulates wrapping the function as needed. I am also moving from using booleans to indicate what the expression's language should be to using lldb::LanguageType instead. llvm-svn: 140545