mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-05-04 23:36:05 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp

850 lines
28 KiB
C++
Raw Normal View History

This commit integrates support for the LLVM MCJIT into the mainline LLDB codebase. MCJIT introduces API improvements and better architectural support. This commit adds a new subsystem, the ProcessDataAllocator, which is responsible for performing static data allocations on behalf of the IR transformer. MCJIT currently does not support the relocations required to store the constant pool in the same allocation as the function body, so we allocate a heap region separately and redirect static data references from the expression to that heap region in a new IR modification pass. This patch also fixes bugs in the IR transformations that were exposed by the transition to the MCJIT. Finally, the patch also pulls in a more recent revision of LLVM so that the MCJIT is available for use. llvm-svn: 131923
2011-05-23 21:40:23 +00:00
//===-- ClangUserExpression.cpp ---------------------------------*- C++ -*-===//
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 08:50:56 +00:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
//
//===----------------------------------------------------------------------===//
#include <stdio.h>
#if HAVE_SYS_TYPES_H
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
#include <sys/types.h>
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
#endif
#include <cstdlib>
#include <map>
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
#include <string>
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
Moved more Clang-specific parts of the expression parser into the Clang plugin. 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-09-25 20:35:58 +00:00
#include "ClangUserExpression.h"
#include "ASTResultSynthesizer.h"
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
#include "ClangDiagnostic.h"
Moved more Clang-specific parts of the expression parser into the Clang plugin. 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-09-25 20:35:58 +00:00
#include "ClangExpressionDeclMap.h"
#include "ClangExpressionParser.h"
Factor the clang specific parts of ExpressionSourceCode.{h,cpp} into the clang plugin. NFC Differential Revision: https://reviews.llvm.org/D59040 llvm-svn: 355560
2019-03-06 22:43:25 +00:00
#include "ClangExpressionSourceCode.h"
Moved more Clang-specific parts of the expression parser into the Clang plugin. 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-09-25 20:35:58 +00:00
#include "ClangModulesDeclVendor.h"
#include "ClangPersistentVariables.h"
Don't omit `this' from expression args if it couldn't be read, but warn loudly. <rdar://problem/26935520> llvm-svn: 273445
2016-06-22 17:32:17 +00:00
#include "lldb/Core/Debugger.h"
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-24 23:10:19 +00:00
#include "lldb/Core/Module.h"
Thread safety changes in debugserver and also in the process GDB remote plugin. I added support for asking if the GDB remote server supports thread suffixes for packets that should be thread specific (register read/write packets) because the way the GDB remote protocol does it right now is to have a notion of a current thread for register and memory reads/writes (set via the "$Hg%x" packet) and a current thread for running ("$Hc%x"). Now we ask the remote GDB server if it supports adding the thread ID to the register packets and we enable that feature in LLDB if supported. This stops us from having to send a bunch of packets that update the current thread ID to some value which is prone to error, or extra packets. llvm-svn: 123762
2011-01-18 19:36:39 +00:00
#include "lldb/Core/StreamFile.h"
Added the notion that a value object can be constant by adding: bool ValueObject::GetIsConstant() const; void ValueObject::SetIsConstant(); This will stop anything from being re-evaluated within the value object so that constant result value objects can maintain their frozen values without anything being updated or changed within the value object. Made it so the ValueObjectConstResult can be constructed with an lldb_private::Error object to allow for expression results to have errors. Since ValueObject objects contain error objects, I changed the expression evaluation in ClangUserExpression from static Error ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr, lldb::ValueObjectSP &result_valobj_sp); to: static lldb::ValueObjectSP Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr); Even though expression parsing is borked right now (pending fixes coming from Sean Callanan), I filled in the implementation for: SBValue SBFrame::EvaluateExpression (const char *expr); Modified all expression code to deal with the above changes. llvm-svn: 115589
2010-10-05 03:13:51 +00:00
#include "lldb/Core/ValueObjectConstResult.h"
Factored out handling of the source code for an 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
2011-09-26 18:45:31 +00:00
#include "lldb/Expression/ExpressionSourceCode.h"
Flipped the big switch: LLDB now uses the new Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
2013-04-16 23:25:35 +00:00
#include "lldb/Expression/IRExecutionUnit.h"
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-18 22:06:33 +00:00
#include "lldb/Expression/IRInterpreter.h"
Added a Materializer class that contains information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
2013-04-11 00:09:05 +00:00
#include "lldb/Expression/Materializer.h"
Move some Host logic into HostInfo class. This patch creates a HostInfo class, a static class used to answer basic queries about the host platform. As part of this change, some functionality is moved from Host to HostInfo, and relevant fixups are performed in the rest of the codebase. This is part of a larger effort to isolate more code in the Host layer into platform-specific groups, to make it easier to make platform specific changes for a particular Host without breaking other hosts. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4963 llvm-svn: 215992
2014-08-19 17:18:29 +00:00
#include "lldb/Host/HostInfo.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-29 21:13:06 +00:00
#include "lldb/Symbol/Block.h"
Make blocks that capture their containing method's object pointer look like methods of the containing class so that direct ivar access will work in the expression parser. <rdar://problem/9797999> llvm-svn: 167061
2012-10-30 23:35:54 +00:00
#include "lldb/Symbol/ClangASTContext.h"
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
#include "lldb/Symbol/ClangExternalASTSourceCommon.h"
Make blocks that capture their containing method's object pointer look like methods of the containing class so that direct ivar access will work in the expression parser. <rdar://problem/9797999> llvm-svn: 167061
2012-10-30 23:35:54 +00:00
#include "lldb/Symbol/Function.h"
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-24 23:10:19 +00:00
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolVendor.h"
Make blocks that capture their containing method's object pointer look like methods of the containing class so that direct ivar access will work in the expression parser. <rdar://problem/9797999> llvm-svn: 167061
2012-10-30 23:35:54 +00:00
#include "lldb/Symbol/Type.h"
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 00:44:12 +00:00
#include "lldb/Symbol/VariableList.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
#include "lldb/Target/ExecutionContext.h"
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 01:54:29 +00:00
#include "lldb/Target/Process.h"
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 09:33:30 +00:00
#include "lldb/Target/StackFrame.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
#include "lldb/Target/Target.h"
Moved the code in ClangUserExpression that set up & ran the thread plan with timeouts, and restarting with all threads into a utility function in Process. This required a bunch of renaming. Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it. Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened. llvm-svn: 120386
2010-11-30 02:22:11 +00:00
#include "lldb/Target/ThreadPlan.h"
#include "lldb/Target/ThreadPlanCallUserExpression.h"
Move classes from Core -> Utility. 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
2017-02-02 21:39:50 +00:00
#include "lldb/Utility/ConstString.h"
Move Log from Core -> Utility. All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
2017-03-03 20:56:28 +00:00
#include "lldb/Utility/Log.h"
Move classes from Core -> Utility. 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
2017-02-02 21:39:50 +00:00
#include "lldb/Utility/StreamString.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
This is an overhaul of the expression parser code that detects what context the current expression is meant to execute in. LLDB now properly consults the method declaration in the debug information rather than trying to hunt down the "this" or "self" pointer by name, which can be misleading. Other fixes include: - LLDB now properly detects that it is inside an inlined C++ member function. - LLDB now allows access to non-const members when in const code. - The functions in SymbolFile that locate the DeclContext containing a DIE have been renamed to reflect what they actually do. I have added new functions that find the DeclContext for the DIE itself. I have also introduced testcases for C++ and Objective-C. llvm-svn: 136999
2011-08-05 23:43:37 +00:00
#include "clang/AST/DeclCXX.h"
#include "clang/AST/DeclObjC.h"
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
using namespace lldb_private;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ClangUserExpression::ClangUserExpression(
Convert some Expression parser functions to StringRef. llvm-svn: 286208
2016-11-08 04:52:16 +00:00
ExecutionContextScope &exe_scope, llvm::StringRef expr,
llvm::StringRef prefix, lldb::LanguageType language,
[Expressions] Add support of expressions evaluation in some object's context Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
2019-02-05 09:14:36 +00:00
ResultType desired_type, const EvaluateExpressionOptions &options,
ValueObject *ctx_obj)
Convert some Expression parser functions to StringRef. llvm-svn: 286208
2016-11-08 04:52:16 +00:00
: LLVMUserExpression(exe_scope, expr, prefix, language, desired_type,
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
options),
Remove redundant ::get() for smart pointer. (NFC) This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
2019-02-12 03:47:39 +00:00
m_type_system_helper(*m_target_wp.lock(), options.GetExecutionPolicy() ==
eExecutionPolicyTopLevel),
m_result_delegate(exe_scope.CalculateTarget()), m_ctx_obj(ctx_obj) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
switch (m_language) {
case lldb::eLanguageTypeC_plus_plus:
m_allow_cxx = true;
break;
case lldb::eLanguageTypeObjC:
m_allow_objc = true;
break;
case lldb::eLanguageTypeObjC_plus_plus:
default:
m_allow_cxx = true;
m_allow_objc = true;
break;
}
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ClangUserExpression::~ClangUserExpression() {}
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
void ClangUserExpression::ScanContext(ExecutionContext &exe_ctx, Status &err) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (log)
log->Printf("ClangUserExpression::ScanContext()");
Added logging to the code that determines whether the current frame is in a C++/Objective-C class or instance method. llvm-svn: 169062
2012-12-01 00:08:33 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_target = exe_ctx.GetTargetPtr();
if (!(m_allow_cxx || m_allow_objc)) {
Added logging to the code that determines whether the current frame is in a C++/Objective-C class or instance method. llvm-svn: 169062
2012-12-01 00:08:33 +00:00
if (log)
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
log->Printf(" [CUE::SC] Settings inhibit C++ and Objective-C");
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
StackFrame *frame = exe_ctx.GetFramePtr();
if (frame == NULL) {
if (log)
log->Printf(" [CUE::SC] Null stack frame");
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
SymbolContext sym_ctx = frame->GetSymbolContext(lldb::eSymbolContextFunction |
lldb::eSymbolContextBlock);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (!sym_ctx.function) {
if (log)
log->Printf(" [CUE::SC] Null function");
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
// Find the block that defines the function represented by "sym_ctx"
Block *function_block = sym_ctx.GetFunctionBlock();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (!function_block) {
if (log)
log->Printf(" [CUE::SC] Null function block");
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
CompilerDeclContext decl_context = function_block->GetDeclContext();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (!decl_context) {
if (log)
log->Printf(" [CUE::SC] Null decl context");
return;
}
[Expressions] Add support of expressions evaluation in some object's context Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
2019-02-05 09:14:36 +00:00
if (m_ctx_obj) {
switch (m_ctx_obj->GetObjectRuntimeLanguage()) {
case lldb::eLanguageTypeC:
case lldb::eLanguageTypeC89:
case lldb::eLanguageTypeC99:
case lldb::eLanguageTypeC11:
case lldb::eLanguageTypeC_plus_plus:
case lldb::eLanguageTypeC_plus_plus_03:
case lldb::eLanguageTypeC_plus_plus_11:
case lldb::eLanguageTypeC_plus_plus_14:
m_in_cplusplus_method = true;
break;
case lldb::eLanguageTypeObjC:
case lldb::eLanguageTypeObjC_plus_plus:
m_in_objectivec_method = true;
break;
default:
break;
}
m_needs_object_ptr = true;
} else if (clang::CXXMethodDecl *method_decl =
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ClangASTContext::DeclContextGetAsCXXMethodDecl(decl_context)) {
if (m_allow_cxx && method_decl->isInstance()) {
if (m_enforce_valid_object) {
lldb::VariableListSP variable_list_sp(
function_block->GetBlockVariableList(true));
const char *thisErrorString = "Stopped in a C++ method, but 'this' "
"isn't available; pretending we are in a "
"generic context";
if (!variable_list_sp) {
err.SetErrorString(thisErrorString);
return;
}
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 00:53:55 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
lldb::VariableSP this_var_sp(
variable_list_sp->FindVariable(ConstString("this")));
if (!this_var_sp || !this_var_sp->IsInScope(frame) ||
!this_var_sp->LocationIsValidForFrame(frame)) {
err.SetErrorString(thisErrorString);
return;
}
}
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 00:53:55 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_in_cplusplus_method = true;
m_needs_object_ptr = true;
Added logging to the code that determines whether the current frame is in a C++/Objective-C class or instance method. llvm-svn: 169062
2012-12-01 00:08:33 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
} else if (clang::ObjCMethodDecl *method_decl =
ClangASTContext::DeclContextGetAsObjCMethodDecl(
decl_context)) {
if (m_allow_objc) {
if (m_enforce_valid_object) {
lldb::VariableListSP variable_list_sp(
function_block->GetBlockVariableList(true));
const char *selfErrorString = "Stopped in an Objective-C method, but "
"'self' isn't available; pretending we "
"are in a generic context";
if (!variable_list_sp) {
err.SetErrorString(selfErrorString);
return;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
lldb::VariableSP self_variable_sp =
variable_list_sp->FindVariable(ConstString("self"));
if (!self_variable_sp || !self_variable_sp->IsInScope(frame) ||
!self_variable_sp->LocationIsValidForFrame(frame)) {
err.SetErrorString(selfErrorString);
return;
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-01 21:35:54 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
m_in_objectivec_method = true;
m_needs_object_ptr = true;
if (!method_decl->isInstanceMethod())
m_in_static_method = true;
Fixed ClangUserExpression's wrapping of expressions in C++ methods. There were two fixes involved: - For an object whose contents are not known, the expression should be treated as a non-member, and "this" should have no meaning. - For a const object, the method should be declared const as well. llvm-svn: 120606
2010-12-01 21:35:54 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
} else if (clang::FunctionDecl *function_decl =
ClangASTContext::DeclContextGetAsFunctionDecl(decl_context)) {
// We might also have a function that said in the debug information that it
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-04-30 16:49:04 +00:00
// captured an object pointer. The best way to deal with getting to the
// ivars at present is by pretending that this is a method of a class in
// whatever runtime the debug info says the object pointer belongs to. Do
// that here.
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ClangASTMetadata *metadata =
ClangASTContext::DeclContextGetMetaData(decl_context, function_decl);
if (metadata && metadata->HasObjectPtr()) {
lldb::LanguageType language = metadata->GetObjectPtrLanguage();
if (language == lldb::eLanguageTypeC_plus_plus) {
if (m_enforce_valid_object) {
lldb::VariableListSP variable_list_sp(
function_block->GetBlockVariableList(true));
const char *thisErrorString = "Stopped in a context claiming to "
"capture a C++ object pointer, but "
"'this' isn't available; pretending we "
"are in a generic context";
if (!variable_list_sp) {
err.SetErrorString(thisErrorString);
return;
}
lldb::VariableSP this_var_sp(
variable_list_sp->FindVariable(ConstString("this")));
if (!this_var_sp || !this_var_sp->IsInScope(frame) ||
!this_var_sp->LocationIsValidForFrame(frame)) {
err.SetErrorString(thisErrorString);
return;
}
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_in_cplusplus_method = true;
m_needs_object_ptr = true;
} else if (language == lldb::eLanguageTypeObjC) {
if (m_enforce_valid_object) {
lldb::VariableListSP variable_list_sp(
function_block->GetBlockVariableList(true));
const char *selfErrorString =
"Stopped in a context claiming to capture an Objective-C object "
"pointer, but 'self' isn't available; pretending we are in a "
"generic context";
if (!variable_list_sp) {
err.SetErrorString(selfErrorString);
return;
}
lldb::VariableSP self_variable_sp =
variable_list_sp->FindVariable(ConstString("self"));
if (!self_variable_sp || !self_variable_sp->IsInScope(frame) ||
!self_variable_sp->LocationIsValidForFrame(frame)) {
err.SetErrorString(selfErrorString);
return;
}
Type *self_type = self_variable_sp->GetType();
if (!self_type) {
err.SetErrorString(selfErrorString);
return;
}
CompilerType self_clang_type = self_type->GetForwardCompilerType();
if (!self_clang_type) {
err.SetErrorString(selfErrorString);
return;
}
if (ClangASTContext::IsObjCClassType(self_clang_type)) {
return;
} else if (ClangASTContext::IsObjCObjectPointerType(
self_clang_type)) {
Rename ClangUserExpression members to avoid confusion with language. The new names clarify that the members have to do with the execution context and not the language. For example, m_cplusplus was renamed to m_in_cplusplus_method. llvm-svn: 241132
2015-07-01 00:54:02 +00:00
m_in_objectivec_method = true;
Factored out handling of the source code for an 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
2011-09-26 18:45:31 +00:00
m_needs_object_ptr = true;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
} else {
err.SetErrorString(selfErrorString);
return;
}
} else {
m_in_objectivec_method = true;
m_needs_object_ptr = true;
Make blocks that capture their containing method's object pointer look like methods of the containing class so that direct ivar access will work in the expression parser. <rdar://problem/9797999> llvm-svn: 167061
2012-10-30 23:35:54 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
Make blocks that capture their containing method's object pointer look like methods of the containing class so that direct ivar access will work in the expression parser. <rdar://problem/9797999> llvm-svn: 167061
2012-10-30 23:35:54 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 00:44:12 +00:00
}
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-04-30 16:49:04 +00:00
// This is a really nasty hack, meant to fix Objective-C expressions of the
// form (int)[myArray count]. Right now, because the type information for
// count is not available, [myArray count] returns id, which can't be directly
// cast to int without causing a clang error.
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
static void ApplyObjcCastHack(std::string &expr) {
Added a temporary hack to allow casting of Objective-C method results to int. This will only last until we get accurate type information for Objective-C methods or some way of making their types inferred by the parser. llvm-svn: 117178
2010-10-22 23:25:16 +00:00
#define OBJC_CAST_HACK_FROM "(int)["
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
#define OBJC_CAST_HACK_TO "(int)(long long)["
Added a temporary hack to allow casting of Objective-C method results to int. This will only last until we get accurate type information for Objective-C methods or some way of making their types inferred by the parser. llvm-svn: 117178
2010-10-22 23:25:16 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
size_t from_offset;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
while ((from_offset = expr.find(OBJC_CAST_HACK_FROM)) != expr.npos)
expr.replace(from_offset, sizeof(OBJC_CAST_HACK_FROM) - 1,
OBJC_CAST_HACK_TO);
Added a temporary hack to allow casting of Objective-C method results to int. This will only last until we get accurate type information for Objective-C methods or some way of making their types inferred by the parser. llvm-svn: 117178
2010-10-22 23:25:16 +00:00
#undef OBJC_CAST_HACK_TO
#undef OBJC_CAST_HACK_FROM
}
Refactor OnExit utility class in ClangUserExpression Summary: OnExit ensures we call `ResetDeclMap` before this method ends. However, we also have a few manual calls to ResetDeclMap in there that are actually unnecessary because of this (calling the method multiple times has no effect). This patch also moves the class out of the method that we can reuse it for the upcoming method that handles parsing for completion. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48337 llvm-svn: 335078
2018-06-19 21:25:59 +00:00
namespace {
// Utility guard that calls a callback when going out of scope.
class OnExit {
public:
typedef std::function<void(void)> Callback;
OnExit(Callback const &callback) : m_callback(callback) {}
~OnExit() { m_callback(); }
private:
Callback m_callback;
};
} // namespace
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
bool ClangUserExpression::SetupPersistentState(DiagnosticManager &diagnostic_manager,
ExecutionContext &exe_ctx) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (Target *target = exe_ctx.GetTargetPtr()) {
if (PersistentExpressionState *persistent_state =
target->GetPersistentExpressionStateForLanguage(
lldb::eLanguageTypeC)) {
m_result_delegate.RegisterPersistentState(persistent_state);
} else {
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
eDiagnosticSeverityError,
"couldn't start parsing (no persistent data)");
return false;
Add PersistentVariableDelegate to handle language-specific dematerialization. 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
2015-10-03 09:09:01 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
} else {
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(eDiagnosticSeverityError,
"error: couldn't start parsing (no target)");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
return false;
}
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
return true;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
static void SetupDeclVendor(ExecutionContext &exe_ctx, Target *target) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (ClangModulesDeclVendor *decl_vendor =
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
target->GetClangModulesDeclVendor()) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
const ClangModulesDeclVendor::ModuleVector &hand_imported_modules =
llvm::cast<ClangPersistentVariables>(
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
target->GetPersistentExpressionStateForLanguage(
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
lldb::eLanguageTypeC))
->GetHandLoadedClangModules();
ClangModulesDeclVendor::ModuleVector modules_for_macros;
for (ClangModulesDeclVendor::ModuleID module : hand_imported_modules) {
modules_for_macros.push_back(module);
Add PersistentVariableDelegate to handle language-specific dematerialization. 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
2015-10-03 09:09:01 +00:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
if (target->GetEnableAutoImportClangModules()) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (StackFrame *frame = exe_ctx.GetFramePtr()) {
if (Block *block = frame->GetFrameBlock()) {
SymbolContext sc;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
block->CalculateSymbolContext(&sc);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (sc.comp_unit) {
StreamString error_stream;
This patch implements several improvements to the module-loading support for the expression parser. - It adds support for auto-loading modules referred to by a compile unit. These references are currently in the form of empty translation units. This functionality is gated by the setting target.auto-import-clang-modules (boolean) = false - It improves and corrects support for loading macros from modules, currently by textually pasting all #defines into the user's expression. The improvements center around including only those modules that are relevant to the current context - hand-loaded modules and the modules that are imported from the current compile unit. - It adds an "opt-in" mechanism for all of this functionality. Modules have to be explicitly imported (via @import) or auto-loaded (by enabling the above setting) to enable any of this functionality. It also adds support to the compile unit and symbol file code to deal with empty translation units that indicate module imports, and plumbs this through to the CompileUnit interface. Finally, it makes the following changes to the test suite: - It adds a testcase that verifies that modules are automatically loaded when the appropriate setting is enabled (lang/objc/modules-auto-import); and - It modifies lanb/objc/modules-incomplete to test the case where a module #undefs something that is #defined in another module. <rdar://problem/20299554> llvm-svn: 235313
2015-04-20 16:31:29 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
decl_vendor->AddModulesForCompileUnit(
*sc.comp_unit, modules_for_macros, error_stream);
}
This patch implements several improvements to the module-loading support for the expression parser. - It adds support for auto-loading modules referred to by a compile unit. These references are currently in the form of empty translation units. This functionality is gated by the setting target.auto-import-clang-modules (boolean) = false - It improves and corrects support for loading macros from modules, currently by textually pasting all #defines into the user's expression. The improvements center around including only those modules that are relevant to the current context - hand-loaded modules and the modules that are imported from the current compile unit. - It adds an "opt-in" mechanism for all of this functionality. Modules have to be explicitly imported (via @import) or auto-loaded (by enabling the above setting) to enable any of this functionality. It also adds support to the compile unit and symbol file code to deal with empty translation units that indicate module imports, and plumbs this through to the CompileUnit interface. Finally, it makes the following changes to the test suite: - It adds a testcase that verifies that modules are automatically loaded when the appropriate setting is enabled (lang/objc/modules-auto-import); and - It modifies lanb/objc/modules-incomplete to test the case where a module #undefs something that is #defined in another module. <rdar://problem/20299554> llvm-svn: 235313
2015-04-20 16:31:29 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
Added support to ClangUserExpression for importing all the macros from the modules the user has loaded. These macros are currently imported textually into the expression's source code, which turns out not to impose the horrific string processing overhead that I thought it would, but I still plan to look into performance improvements. Also modified TestCModules to test that this works. llvm-svn: 234922
2015-04-14 18:36:17 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
void ClangUserExpression::UpdateLanguageForExpr(
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
DiagnosticManager &diagnostic_manager, ExecutionContext &exe_ctx) {
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
m_expr_lang = lldb::LanguageType::eLanguageTypeUnknown;
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
std::string prefix = m_expr_prefix;
Figure out what the fixed expression is, and print it. Added another target 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-03-29 22:00:08 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (m_options.GetExecutionPolicy() == eExecutionPolicyTopLevel) {
m_transformed_text = m_expr_text;
} else {
Factor the clang specific parts of ExpressionSourceCode.{h,cpp} into the clang plugin. NFC Differential Revision: https://reviews.llvm.org/D59040 llvm-svn: 355560
2019-03-06 22:43:25 +00:00
std::unique_ptr<ClangExpressionSourceCode> source_code(
ClangExpressionSourceCode::CreateWrapped(prefix.c_str(),
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_expr_text.c_str()));
if (m_in_cplusplus_method)
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
m_expr_lang = lldb::eLanguageTypeC_plus_plus;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
else if (m_in_objectivec_method)
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
m_expr_lang = lldb::eLanguageTypeObjC;
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 00:44:12 +00:00
else
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
m_expr_lang = lldb::eLanguageTypeC;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
if (!source_code->GetText(m_transformed_text, m_expr_lang,
[Expressions] Add support of expressions evaluation in some object's context Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
2019-02-05 09:14:36 +00:00
m_in_static_method, exe_ctx,
!m_ctx_obj)) {
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(eDiagnosticSeverityError,
"couldn't construct expression body");
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
return;
Removed the hacky "#define this ___clang_this" handler for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
2010-09-21 00:44:12 +00:00
}
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
// Find and store the start position of the original code inside the
// transformed code. We need this later for the code completion.
std::size_t original_start;
std::size_t original_end;
bool found_bounds = source_code->GetOriginalBodyBounds(
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
m_transformed_text, m_expr_lang, original_start, original_end);
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
if (found_bounds) {
m_user_expression_start_pos = original_start;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
}
bool ClangUserExpression::PrepareForParsing(
DiagnosticManager &diagnostic_manager, ExecutionContext &exe_ctx) {
InstallContext(exe_ctx);
if (!SetupPersistentState(diagnostic_manager, exe_ctx))
return false;
Status err;
ScanContext(exe_ctx, err);
if (!err.Success()) {
diagnostic_manager.PutString(eDiagnosticSeverityWarning, err.AsCString());
}
////////////////////////////////////
// Generate the expression
//
ApplyObjcCastHack(m_expr_text);
SetupDeclVendor(exe_ctx, m_target);
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
UpdateLanguageForExpr(diagnostic_manager, exe_ctx);
Refactor ClangUserExpression::Parse [NFC] Summary: This patch splits out functionality from the `Parse` method into different methods. This benefits the code completion work (which should reuse those methods) and makes the code a bit more readable. Note that this patch is as minimal as possible. Some of the code in the new methods definitely needs more refactoring. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48339 llvm-svn: 336734
2018-07-10 22:12:39 +00:00
return true;
}
bool ClangUserExpression::Parse(DiagnosticManager &diagnostic_manager,
ExecutionContext &exe_ctx,
lldb_private::ExecutionPolicy execution_policy,
bool keep_result_in_memory,
bool generate_debug_info) {
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
if (!PrepareForParsing(diagnostic_manager, exe_ctx))
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (log)
log->Printf("Parsing the following code:\n%s", m_transformed_text.c_str());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
////////////////////////////////////
// Set up the target and compiler
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
Target *target = exe_ctx.GetTargetPtr();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (!target) {
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(eDiagnosticSeverityError, "invalid target");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
//////////////////////////
// Parse the expression
//
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 06:25:41 +00:00
m_materializer_up.reset(new Materializer());
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ResetDeclMap(exe_ctx, m_result_delegate, keep_result_in_memory);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
OnExit on_exit([this]() { ResetDeclMap(); });
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 06:25:41 +00:00
if (!DeclMap()->WillParse(exe_ctx, m_materializer_up.get())) {
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
eDiagnosticSeverityError,
"current process state is unsuitable for expression parsing");
return false;
}
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (m_options.GetExecutionPolicy() == eExecutionPolicyTopLevel) {
DeclMap()->SetLookupsEnabled(true);
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
Process *process = exe_ctx.GetProcessPtr();
ExecutionContextScope *exe_scope = process;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (!exe_scope)
exe_scope = exe_ctx.GetTargetPtr();
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
// We use a shared pointer here so we can use the original parser - if it
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-04-30 16:49:04 +00:00
// succeeds or the rewrite parser we might make if it fails. But the
// parser_sp will never be empty.
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ClangExpressionParser parser(exe_scope, *this, generate_debug_info);
unsigned num_errors = parser.Parse(diagnostic_manager);
// Check here for FixItHints. If there are any try to apply the fixits and
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-04-30 16:49:04 +00:00
// set the fixed text in m_fixed_text before returning an error.
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (num_errors) {
if (diagnostic_manager.HasFixIts()) {
if (parser.RewriteExpression(diagnostic_manager)) {
size_t fixed_start;
size_t fixed_end;
const std::string &fixed_expression =
diagnostic_manager.GetFixedExpression();
Factor the clang specific parts of ExpressionSourceCode.{h,cpp} into the clang plugin. NFC Differential Revision: https://reviews.llvm.org/D59040 llvm-svn: 355560
2019-03-06 22:43:25 +00:00
if (ClangExpressionSourceCode::GetOriginalBodyBounds(
Refactor ClangUserExpression::GetLanguageForExpr Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
2018-09-27 10:12:54 +00:00
fixed_expression, m_expr_lang, fixed_start, fixed_end))
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_fixed_text =
fixed_expression.substr(fixed_start, fixed_end - fixed_start);
}
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
return false;
}
//////////////////////////////////////////////////////////////////////////////////////////
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-04-30 16:49:04 +00:00
// Prepare the output of the parser for execution, evaluating it statically
// if possible
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
//
{
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Status jit_error = parser.PrepareForExecution(
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_jit_start_addr, m_jit_end_addr, m_execution_unit_sp, exe_ctx,
m_can_interpret, execution_policy);
if (!jit_error.Success()) {
const char *error_cstr = jit_error.AsCString();
if (error_cstr && error_cstr[0])
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(eDiagnosticSeverityError, error_cstr);
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
else
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(eDiagnosticSeverityError,
"expression can't be interpreted or run");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
return false;
}
}
if (exe_ctx.GetProcessPtr() && execution_policy == eExecutionPolicyTopLevel) {
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Status static_init_error =
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
parser.RunStaticInitializers(m_execution_unit_sp, exe_ctx);
if (!static_init_error.Success()) {
const char *error_cstr = static_init_error.AsCString();
if (error_cstr && error_cstr[0])
diagnostic_manager.Printf(eDiagnosticSeverityError,
"couldn't run static initializers: %s\n",
error_cstr);
else
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(eDiagnosticSeverityError,
"couldn't run static initializers\n");
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
return false;
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (m_execution_unit_sp) {
bool register_execution_unit = false;
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (m_options.GetExecutionPolicy() == eExecutionPolicyTopLevel) {
register_execution_unit = true;
}
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-04-30 16:49:04 +00:00
// If there is more than one external function in the execution unit, it
// needs to keep living even if it's not top level, because the result
// could refer to that function.
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (m_execution_unit_sp->GetJittedFunctions().size() > 1) {
register_execution_unit = true;
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (register_execution_unit) {
llvm::cast<PersistentExpressionState>(
exe_ctx.GetTargetPtr()->GetPersistentExpressionStateForLanguage(
m_language))
->RegisterExecutionUnit(m_execution_unit_sp);
}
}
if (generate_debug_info) {
lldb::ModuleSP jit_module_sp(m_execution_unit_sp->GetJITModule());
if (jit_module_sp) {
ConstString const_func_name(FunctionName());
FileSpec jit_file;
jit_file.GetFilename() = const_func_name;
jit_module_sp->SetFileSpecAndObjectName(jit_file, ConstString());
m_jit_module_wp = jit_module_sp;
target->GetImages().Append(jit_module_sp);
JITed functions can now have debug info and be debugged with debug and source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
2014-03-24 23:10:19 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (process && m_jit_start_addr != LLDB_INVALID_ADDRESS)
m_jit_process_wp = lldb::ProcessWP(process->shared_from_this());
return true;
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
}
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
//------------------------------------------------------------------
/// Converts an absolute position inside a given code string into
/// a column/line pair.
///
/// @param[in] abs_pos
/// A absolute position in the code string that we want to convert
/// to a column/line pair.
///
/// @param[in] code
/// A multi-line string usually representing source code.
///
/// @param[out] line
/// The line in the code that contains the given absolute position.
/// The first line in the string is indexed as 1.
///
/// @param[out] column
/// The column in the line that contains the absolute position.
/// The first character in a line is indexed as 0.
//------------------------------------------------------------------
Change type of m_user_expression_start_pos to size_t AbsPosToLineColumnPos is the only reader of m_user_expression_start_pos and actually treats it like a size_t. Also the value we store in m_user_expression_start_pos is originally a size_t, so it makes sense to change the type of this variable to size_t. llvm-svn: 342804
2018-09-22 13:33:08 +00:00
static void AbsPosToLineColumnPos(size_t abs_pos, llvm::StringRef code,
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
unsigned &line, unsigned &column) {
// Reset to code position to beginning of the file.
line = 0;
column = 0;
assert(abs_pos <= code.size() && "Absolute position outside code string?");
// We have to walk up to the position and count lines/columns.
for (std::size_t i = 0; i < abs_pos; ++i) {
// If we hit a line break, we go back to column 0 and enter a new line.
// We only handle \n because that's what we internally use to make new
// lines for our temporary code strings.
if (code[i] == '\n') {
++line;
column = 0;
continue;
}
++column;
}
}
bool ClangUserExpression::Complete(ExecutionContext &exe_ctx,
Use a CompletionRequest in the expression command completion [NFC] The patch was originally written before we had a CompletionRequest, so it still used a StringList to pass back the completions to the request. llvm-svn: 341124
2018-08-30 21:26:32 +00:00
CompletionRequest &request,
unsigned complete_pos) {
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
// We don't want any visible feedback when completing an expression. Mostly
// because the results we get from an incomplete invocation are probably not
// correct.
DiagnosticManager diagnostic_manager;
if (!PrepareForParsing(diagnostic_manager, exe_ctx))
return false;
if (log)
log->Printf("Parsing the following code:\n%s", m_transformed_text.c_str());
//////////////////////////
// Parse the expression
//
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 06:25:41 +00:00
m_materializer_up.reset(new Materializer());
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
ResetDeclMap(exe_ctx, m_result_delegate, /*keep result in memory*/ true);
OnExit on_exit([this]() { ResetDeclMap(); });
Replace 'ap' with 'up' suffix in variable names. (NFC) The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-13 06:25:41 +00:00
if (!DeclMap()->WillParse(exe_ctx, m_materializer_up.get())) {
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
diagnostic_manager.PutString(
eDiagnosticSeverityError,
"current process state is unsuitable for expression parsing");
return false;
}
if (m_options.GetExecutionPolicy() == eExecutionPolicyTopLevel) {
DeclMap()->SetLookupsEnabled(true);
}
Process *process = exe_ctx.GetProcessPtr();
ExecutionContextScope *exe_scope = process;
if (!exe_scope)
exe_scope = exe_ctx.GetTargetPtr();
ClangExpressionParser parser(exe_scope, *this, false);
// We have to find the source code location where the user text is inside
// the transformed expression code. When creating the transformed text, we
// already stored the absolute position in the m_transformed_text string. The
// only thing left to do is to transform it into the line:column format that
// Clang expects.
// The line and column of the user expression inside the transformed source
// code.
unsigned user_expr_line, user_expr_column;
if (m_user_expression_start_pos.hasValue())
AbsPosToLineColumnPos(*m_user_expression_start_pos, m_transformed_text,
user_expr_line, user_expr_column);
else
return false;
// The actual column where we have to complete is the start column of the
// user expression + the offset inside the user code that we were given.
const unsigned completion_column = user_expr_column + complete_pos;
Use a CompletionRequest in the expression command completion [NFC] The patch was originally written before we had a CompletionRequest, so it still used a StringList to pass back the completions to the request. llvm-svn: 341124
2018-08-30 21:26:32 +00:00
parser.Complete(request, user_expr_line, completion_column, complete_pos);
Added initial code completion support for the `expr` command Summary: This patch adds initial code completion support for the `expr` command. We now have a completion handler in the expression CommandObject that essentially just attempts to parse the given user expression with Clang with an attached code completion consumer. We filter and prepare the code completions provided by Clang and send them back to the completion API. The current completion is limited to variables that are in the current scope. This includes local variables and all types used by local variables. We however don't do any completion of symbols that are not used in the local scope (or in some other way already in the ASTContext). This is partly because there is not yet any code that manually searches for additiona information in the debug information. Another cause is that for some reason the existing code for loading these additional symbols when requested by Clang doesn't seem to work. This will be fixed in a future patch. Reviewers: jingham, teemperor Reviewed By: teemperor Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48465 llvm-svn: 341086
2018-08-30 17:29:37 +00:00
return true;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
bool ClangUserExpression::AddArguments(ExecutionContext &exe_ctx,
std::vector<lldb::addr_t> &args,
lldb::addr_t struct_address,
DiagnosticManager &diagnostic_manager) {
lldb::addr_t object_ptr = LLDB_INVALID_ADDRESS;
lldb::addr_t cmd_ptr = LLDB_INVALID_ADDRESS;
if (m_needs_object_ptr) {
lldb::StackFrameSP frame_sp = exe_ctx.GetFrameSP();
if (!frame_sp)
return true;
ConstString object_name;
if (m_in_cplusplus_method) {
object_name.SetCString("this");
} else if (m_in_objectivec_method) {
object_name.SetCString("self");
} else {
Make DiagnosticsManager functions take StringRefs. llvm-svn: 286730
2016-11-12 19:12:56 +00:00
diagnostic_manager.PutString(
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
eDiagnosticSeverityError,
"need object pointer but don't know the language");
return false;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Status object_ptr_error;
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
[Expressions] Add support of expressions evaluation in some object's context Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
2019-02-05 09:14:36 +00:00
if (m_ctx_obj) {
AddressType address_type;
object_ptr = m_ctx_obj->GetAddressOf(false, &address_type);
if (object_ptr == LLDB_INVALID_ADDRESS ||
address_type != eAddressTypeLoad)
object_ptr_error.SetErrorString("Can't get context object's "
"debuggee address");
} else
object_ptr = GetObjectPointer(frame_sp, object_name, object_ptr_error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (!object_ptr_error.Success()) {
exe_ctx.GetTargetRef().GetDebugger().GetAsyncOutputStream()->Printf(
Fix spelling mistake. llvm-svn: 295694
2017-02-21 05:09:26 +00:00
"warning: `%s' is not accessible (substituting 0)\n",
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
object_name.AsCString());
object_ptr = 0;
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (m_in_objectivec_method) {
ConstString cmd_name("_cmd");
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
cmd_ptr = GetObjectPointer(frame_sp, cmd_name, object_ptr_error);
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (!object_ptr_error.Success()) {
diagnostic_manager.Printf(
eDiagnosticSeverityWarning,
"couldn't get cmd pointer (substituting NULL): %s",
object_ptr_error.AsCString());
cmd_ptr = 0;
}
}
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-18 22:06:33 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
args.push_back(object_ptr);
This commit changes the way LLDB executes user expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
2013-04-18 22:06:33 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
if (m_in_objectivec_method)
args.push_back(cmd_ptr);
args.push_back(struct_address);
} else {
args.push_back(struct_address);
}
return true;
This is a major refactoring of the expression parser. The goal is to separate the parser's data from the data belonging to the parser's clients. This allows clients to use the parser to obtain (for example) a JIT compiled function or some DWARF code, and then discard the parser state. Previously, parser state was held in ClangExpression and used liberally by ClangFunction, which inherited from ClangExpression. The main effects of this refactoring are: - reducing ClangExpression to an abstract class that declares methods that any client must expose to the expression parser, - moving the code specific to implementing the "expr" command from ClangExpression and CommandObjectExpression into ClangUserExpression, a new class, - moving the common parser interaction code from ClangExpression into ClangExpressionParser, a new class, and - making ClangFunction rely only on ClangExpressionParser and not depend on the internal implementation of ClangExpression. Side effects include: - the compiler interaction code has been factored out of ClangFunction and is now in an AST pass (ASTStructExtractor), - the header file for ClangFunction is now fully documented, - several bugs that only popped up when Clang was deallocated (which never happened, since the lifetime of the compiler was essentially infinite) are now fixed, and - the developer-only "call" command has been disabled. I have tested the expr command and the Objective-C step-into code, which use ClangUserExpression and ClangFunction, respectively, and verified that they work. Please let me know if you encounter bugs or poor documentation. llvm-svn: 112249
2010-08-27 01:01:44 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
lldb::ExpressionVariableSP ClangUserExpression::GetResultAfterDematerialization(
ExecutionContextScope *exe_scope) {
return m_result_delegate.GetVariable();
Add PersistentVariableDelegate to handle language-specific dematerialization. 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
2015-10-03 09:09:01 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
void ClangUserExpression::ClangUserExpressionHelper::ResetDeclMap(
ExecutionContext &exe_ctx,
Materializer::PersistentVariableDelegate &delegate,
[Expressions] Add support of expressions evaluation in some object's context Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
2019-02-05 09:14:36 +00:00
bool keep_result_in_memory,
ValueObject *ctx_obj) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_expr_decl_map_up.reset(
[Expressions] Add support of expressions evaluation in some object's context Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
2019-02-05 09:14:36 +00:00
new ClangExpressionDeclMap(keep_result_in_memory, &delegate, exe_ctx,
ctx_obj));
This patch makes Clang-independent base classes for all the expression types that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
2015-09-15 21:13:50 +00:00
}
remove trailing whitespace + remove some useless comments llvm-svn: 212411
2014-07-06 17:54:58 +00:00
This patch makes Clang-independent base classes for all the expression types that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
2015-09-15 21:13:50 +00:00
clang::ASTConsumer *
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ClangUserExpression::ClangUserExpressionHelper::ASTTransformer(
clang::ASTConsumer *passthrough) {
m_result_synthesizer_up.reset(
new ASTResultSynthesizer(passthrough, m_top_level, m_target));
Added the notion that a value object can be constant by adding: bool ValueObject::GetIsConstant() const; void ValueObject::SetIsConstant(); This will stop anything from being re-evaluated within the value object so that constant result value objects can maintain their frozen values without anything being updated or changed within the value object. Made it so the ValueObjectConstResult can be constructed with an lldb_private::Error object to allow for expression results to have errors. Since ValueObject objects contain error objects, I changed the expression evaluation in ClangUserExpression from static Error ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr, lldb::ValueObjectSP &result_valobj_sp); to: static lldb::ValueObjectSP Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr); Even though expression parsing is borked right now (pending fixes coming from Sean Callanan), I filled in the implementation for: SBValue SBFrame::EvaluateExpression (const char *expr); Modified all expression code to deal with the above changes. llvm-svn: 115589
2010-10-05 03:13:51 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
return m_result_synthesizer_up.get();
ClangUserExpression ctor should not crash if given a null expr_prefix char*. llvm-svn: 117700
2010-10-29 20:19:44 +00:00
}
This patch makes Clang-independent base classes for all the expression types that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
2015-09-15 21:13:50 +00:00
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
void ClangUserExpression::ClangUserExpressionHelper::CommitPersistentDecls() {
Remove redundant ::get() for smart pointer. (NFC) This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
2019-02-12 03:47:39 +00:00
if (m_result_synthesizer_up) {
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
m_result_synthesizer_up->CommitPersistentDecls();
}
Backend support for top-level Clang epxressions 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
2016-03-22 21:05:51 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
ConstString ClangUserExpression::ResultDelegate::GetName() {
Refactor GetNextPersistentVariableName into a non-virtual method that takes a prefix string. This simplifies the implementation and allows plugins such as the Swift plugin to supply different prefixes for return and error variables. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46088 llvm-svn: 331235
2018-04-30 23:59:17 +00:00
auto prefix = m_persistent_state->GetPersistentVariablePrefix();
return m_persistent_state->GetNextPersistentVariableName(*m_target_sp,
prefix);
Add PersistentVariableDelegate to handle language-specific dematerialization. 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
2015-10-03 09:09:01 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
void ClangUserExpression::ResultDelegate::DidDematerialize(
lldb::ExpressionVariableSP &variable) {
m_variable = variable;
Add PersistentVariableDelegate to handle language-specific dematerialization. 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
2015-10-03 09:09:01 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
void ClangUserExpression::ResultDelegate::RegisterPersistentState(
PersistentExpressionState *persistent_state) {
m_persistent_state = persistent_state;
Add PersistentVariableDelegate to handle language-specific dematerialization. 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
2015-10-03 09:09:01 +00:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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-09-06 20:57:50 +00:00
lldb::ExpressionVariableSP &ClangUserExpression::ResultDelegate::GetVariable() {
return m_variable;
Add PersistentVariableDelegate to handle language-specific dematerialization. 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
2015-10-03 09:09:01 +00:00
}
Reference in New Issue Copy Permalink