summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add missing nullptr checks.Adrian Prantl2020-01-101-8/+11
| | | | | | | | | | GetPersistentExpressionStateForLanguage() can return a nullptr if it cannot construct a typesystem. This patch adds missing nullptr checks at all uses. Inspired by rdar://problem/58317195 Differential Revision: https://reviews.llvm.org/D72413
* [lldb][NFC] Remove ClangExternalASTSourceCommonRaphael Isemann2019-12-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | ClangExternalASTSourceCommon's purpose is to store a map from Decl*/Type* to ClangASTMetadata. Usually this data is accessed via the ClangASTContext interface which then grabs the current ExternalASTSource of its ASTContext, tries to cast it to ClangExternalASTSourceCommon and then accesses the metadata map. If the casting fails the setter does nothing and the getter returns a nullptr as if there was no known metadata for a type/decl. This system breaks as soon as any non-LLDB ExternalASTSource is added via a multiplexer to our existing ExternalASTSource (in which case we suddenly loose all out metadata as the casting always fails with an ExternalASTSource that is not inheriting from ClangExternalASTSourceCommon). This patch moves the metadata map to the ClangASTContext. This gets rid of all the fragile casting, the requirement that every ExternalASTSource in LLDB has to inherit from ClangExternalASTSourceCommon and simplifies the metadata implementation to a simple map lookup. As ClangExternalASTSourceCommon had no other purpose than storing metadata, this patch deletes this class and replaces all uses with clang::ExternalASTSource. No other code changes in this commit beside the AppleObjCDeclVendor which was the only code that did not use the ClangASTContext interface but directly accessed the ClangExternalASTSourceCommon.
* [lldb][NFC] Allow creating ClangExpressionDeclMap and ClangASTSource without ↵Raphael Isemann2019-12-171-3/+3
| | | | | | | | | | a Target and add basic unit test The ClangExpressionDeclMap should be testable from a unit test. This is currently impossible as they have both dependencies on Target/ExecutionContext from their constructor. This patch allows constructing these classes without an active Target and adds the missing tests for running without a target that we can do at least a basic lookup test without crashing.
* [lldb][NFC] Remove all unnecessary includes for ClangASTSourceCommon.hRaphael Isemann2019-12-171-1/+0
| | | | | These files only need the definition of ClangASTMetadata (which was previously in the ClangASTSourceCommon.h) or don't need the include at all.
* Use ForEachExternalModule in ParseTypeFromClangModule (NFC)Adrian Prantl2019-11-141-9/+13
| | | | | | | | | | | I wanted to further simplify ParseTypeFromClangModule by replacing the hand-rolled loop with ForEachExternalModule, and then realized that ForEachExternalModule also had the problem of visiting the same leaf node an exponential number of times in the worst-case. This adds a set of searched_symbol_files set to the function as well as the ability to early-exit from it. Differential Revision: https://reviews.llvm.org/D70215
* [lldb][NFC] Move LLVM RTTI implementation from enum to static ID variableRaphael Isemann2019-11-121-1/+3
| | | | | | | | | | | | | | | | Summary: swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI with a static ID variable instead of a centralised enum we can drop that patch. Reviewers: labath, davide Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #upstreaming_lldb_s_downstream_patches, #lldb Differential Revision: https://reviews.llvm.org/D70070
* [lldb] Provide a getter for m_materializer_up in LLVMUserExpression instead ↵Raphael Isemann2019-11-041-2/+2
| | | | | | | | | | | | | | | | | | of relying on it being accessible. Summary: Motivated by Swift using the materializer in a few places which requires us to add this getter ourselves. We also need a setter, but let's keep this minimal to unblock the downstream reverts in Swift. Reviewers: davide Reviewed By: davide Subscribers: abidh, JDevlieghere, lldb-commits Tags: #upstreaming_lldb_s_downstream_patches, #lldb Differential Revision: https://reviews.llvm.org/D69714
* [lldb] Add log output for the support files we pass to the ↵Raphael Isemann2019-10-101-0/+11
| | | | | | | | | | | CppModuleConfiguration CppModuleConfiguration is the most likely point of failure when we have weird setups where we fail to load a C++ module. With this logging it should be easier to figure out why we can't find a valid configuration as the configuration only depends on the list of file paths. llvm-svn: 374350
* [lldb] Fix undefined behavior when having fixits in undefined top level exprsRaphael Isemann2019-09-251-1/+4
| | | | | | | | In top level expressions, we don't have a m_source_code and we don't need to change the source bounds (as no wrapping happend there). Fixes the test on the sanitizer bot. llvm-svn: 372817
* [lldb] Decouple importing the std C++ module from the way the program is ↵Raphael Isemann2019-09-241-31/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
* [lldb] Print better diagnostics for user expressions and modulesRaphael Isemann2019-09-181-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions. For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong: ``` (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) error: invalid operands to binary expression ('int' and 'double') ``` This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this: ``` (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float') printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) ~~~~~~^~~~ ``` To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to our internal wrapper code we inject. Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function) will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible. We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message without any context (and the original diagnostic in the user expression should be enough to explain the issue). Fixes rdar://24306342 Reviewers: JDevlieghere, aprantl, shafik, #lldb Reviewed By: JDevlieghere, #lldb Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65646 llvm-svn: 372203
* Reland "[lldb][NFC] Make ApplyObjcCastHack less scary"Raphael Isemann2019-09-171-9/+5
| | | | | | First version had a typo. llvm-svn: 372077
* Revert "[lldb][NFC] Make ApplyObjcCastHack less scary"Jim Ingham2019-09-171-5/+9
| | | | | | | | | | | | | | This reverts commit 21641a2f6dbac22653befd03496e0850537882ff. It was causing the following test failures: lldb-Suite.lang/objc/objc-class-method.TestObjCClassMethod.py lldb-Suite.lang/objc/foundation.TestObjCMethodsString.py lldb-Suite.lang/objc/foundation.TestConstStrings.py lldb-Suite.lang/objc/radar-9691614.TestObjCMethodReturningBOOL.py lldb-Suite.lang/objc/foundation.TestObjCMethodsNSArray.py llvm-svn: 372057
* [lldb][NFC] Make ApplyObjcCastHack less scaryRaphael Isemann2019-09-161-9/+5
| | | | llvm-svn: 372017
* [lldb][NFC] Make include directories in Clang expression parser a std::stringRaphael Isemann2019-09-111-1/+1
| | | | | | | | | We never compare these directories (where ConstString would be good) and essentially just convert this back to a normal string in the end. So we might as well just use std::string. Also makes it easier to unittest this code (which was the main motivation for this change). llvm-svn: 371623
* Detect HAVE_SYS_TYPES_H in lldbHaibo Huang2019-08-071-0/+2
| | | | | | | | | | | | | | | | Summary: After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in Platform.h, or anywhere else in lldb. This change fixes that. Reviewers: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65822 llvm-svn: 368125
* [lldb][NFC] Remove unnecessary cast in ClangUserExpressionRaphael Isemann2019-08-061-5/+3
| | | | llvm-svn: 367989
* [lldb][NFC] Refactor ClangUserExpression::UpdateLanguageForExprRaphael Isemann2019-08-051-12/+16
| | | | | | | | | The UpdateLanguageForExpr should only update the language, but over time it started to do also do different things related to the generation of the expression source code. This patch refactors all the source code generation part into its own function. llvm-svn: 367922
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-16/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Inject only relevant local variables in the expression evaluation contextRaphael Isemann2019-05-021-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In r259902, LLDB started injecting all the locals in every expression evaluation. This fixed a bunch of issues, but also caused others, mostly performance regressions on some codebases. The regressions were bad enough that we added a setting in r274783 to control the behavior and we have been shipping with the setting off to avoid the perf regressions. This patch changes the logic injecting the local variables to only inject the ones present in the expression typed by the user. The approach is fairly simple and just scans the typed expression for every local name. Hopefully this gives us the best of both world as it just realizes the types of the variables really used by the expression. Landing this requires the 2 other issues I pointed out today to be addressed but I wanted to gather comments right away. Original patch by Frédéric Riss! Reviewers: jingham, clayborg, friss, shafik Reviewed By: jingham, clayborg Subscribers: teemperor, labath, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D46551 llvm-svn: 359773
* Replace local utility class OnExit with llvm::scope_exit (NFC)Tatyana Krasnukha2019-04-261-17/+4
| | | | llvm-svn: 359319
* Allow direct comparison of ConstString against StringRefRaphael Isemann2019-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
* Minor code style fix in ClangUserExpression.cpp [NFC]Raphael Isemann2019-04-241-2/+1
| | | | llvm-svn: 359089
* Shorten comment line to be below 80 characters [NFC]Raphael Isemann2019-04-241-1/+1
| | | | llvm-svn: 359087
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Fix an invalid static cast in ClangExpressionParser.cppAdrian Prantl2019-03-131-1/+1
| | | | | | | | | | This was found by the green dragon sanitizer bot. rdar://problem/48536644 Differential Revision: https://reviews.llvm.org/D59314 llvm-svn: 356090
* Add ability to import std module into expression parser to improve C++ debuggingRaphael Isemann2019-03-121-5/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging. What happens in this patch is that we inject a `@import std` into our expression source code. We also modify our internal Clang instance for parsing this expression to work with modules and debug info at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The C++ include paths for building are extracted from the debug info, which means that this currently only works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths are currently specified by LLDB. I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific C include paths for them). With this patch we can now: * Build a libc++ as a module and import it into the expression parser. * Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`. What doesn't work (yet): * Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work. * Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't call yet any function that returns a non-trivial type. * Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches. Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille Reviewed By: aprantl Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D58125 llvm-svn: 355939
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-111-4/+4
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* Factor the clang specific parts of ExpressionSourceCode.{h,cpp} into the ↵Jim Ingham2019-03-061-3/+4
| | | | | | | | | | clang plugin. NFC Differential Revision: https://reviews.llvm.org/D59040 llvm-svn: 355560
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-4/+4
| | | | | | | | | | | | | | | | | 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
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-121-6/+4
| | | | | | | | 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
* [Expressions] Add support of expressions evaluation in some object's contextAleksandr Urakov2019-02-051-7/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Refactor ClangUserExpression::GetLanguageForExprRaphael Isemann2018-09-271-18/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Change type of m_user_expression_start_pos to size_tRaphael Isemann2018-09-221-1/+1
| | | | | | | | | 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
* Reland [ClangUserExpression][NFC] Removed unused codeRaphael Isemann2018-09-061-3/+1
| | | | | | | | The GetLanguageForExpr has side effects, so we can't remove this call without breaking the completion mechanism. However, we can keep the change that gets rid of this unnecessary variable. llvm-svn: 341535
* Revert "[ClangUserExpression][NFC] Removed unused code"Raphael Isemann2018-09-061-0/+4
| | | | | | | GetLanguageForExpr has side effects, so this actually breaks the completion. Should fix TestExprCompletion. llvm-svn: 341532
* [ClangUserExpression][NFC] Removed unused codeDavid Bolvansky2018-09-031-4/+0
| | | | llvm-svn: 341334
* Use a CompletionRequest in the expression command completion [NFC]Raphael Isemann2018-08-301-2/+3
| | | | | | | | 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
* Added initial code completion support for the `expr` commandRaphael Isemann2018-08-301-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor ClangUserExpression::Parse [NFC]Raphael Isemann2018-07-101-30/+56
| | | | | | | | | | | | | | | | 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
* Refactor OnExit utility class in ClangUserExpressionRaphael Isemann2018-06-191-24/+15
| | | | | | | | | | | | | | | 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
* Refactor GetNextPersistentVariableName into a non-virtual methodAdrian Prantl2018-04-301-1/+3
| | | | | | | | | | | | 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
* Move the persistent variable counter into TargetAdrian Prantl2018-04-301-4/+3
| | | | | | | | | | | | | | | | | so it can be shared across multiple language plugins. In a multi-language project it is counterintuitive to have a result variables reuse numbers just because they are using a different language plugin in LLDB (but not for example, when they are Objective-C versus C++, since they are both handled by Clang). This is NFC on llvm.org except for the Go plugin. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46083 llvm-svn: 331234
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-20/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove some unused function calls from ClangUserExpression.cppStephane Sezer2017-10-241-1/+0
| | | | llvm-svn: 316527
* Rename Error -> Status.Zachary Turner2017-05-121-5/+5
| | | | | | | | | | | | | | | 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
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | 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
* Fix spelling mistake.Jason Molenda2017-02-211-1/+1
| | | | llvm-svn: 295694
OpenPOWER on IntegriCloud