summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb][NFC] Remove ClangASTContext::GetUniqueNamespaceDeclaration overloadRaphael Isemann2019-11-201-4/+6
| | | | | | This overload is only used in one place and having static overloads for all methods that only do an additional clang::ASTContext -> ClangASTContext conversion is just not sustainable.
* [lldb] Remove ClangExpressionDeclMap::ResolveUnknownTypesRaphael Isemann2019-11-193-90/+0
| | | | | | | | | | | | | | | | | | | | | Summary: This is some really shady code. It's supposed to kick in after an expression already failed and then try to look up "unknown types" that for some undocumented reason can't be resolved during/before parsing. Beside the fact that we never mark any type as `EVUnknownType` in either swift-lldb or lldb (which means this code is unreachable), this code doesn't even make the expression evaluation succeed if if would ever be executed but instead seems to try to load more debug info that maybe any following expression evaluations might succeed. This patch removes ClangExpressionDeclMap::ResolveUnknownTypes and the related data structures/checks/calls. Reviewers: davide Reviewed By: davide Subscribers: aprantl, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70388
* [lldb][NFC] Cleanup comments in ClangASTSource.hRaphael Isemann2019-11-181-22/+23
| | | | | The current file doesn't follow the 80 character limit and uses this cramped comment style that is hard to read.
* Avoid including Builtins.h in Preprocessor.hReid Kleckner2019-11-151-0/+1
| | | | | | Builtins are rarely if ever accessed via the Preprocessor. They are typically found on the ASTContext, so there should be no performance penalty to using a pointer indirection to store the builtin context.
* Fix -Wunused-result warnings in LLDBReid Kleckner2019-11-151-1/+1
| | | | | | | | | | Three uses of try_lock intentionally ignore the result, as explained in the comment. Make that explicit with a void cast. Add what appears to be a missing return in the clang expression parser code. It's a functional change, but presumably the right one. Differential Revision: https://reviews.llvm.org/D70281
* 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] Fix a bunch of -Wdocumentation warnings in ExpressionParserJonas Devlieghere2019-11-136-111/+35
|
* [LLDB] Fix a bunch of -Wdocumentation warningsJonas Devlieghere2019-11-135-14/+4
|
* [lldb][NFC] Move LLVM RTTI implementation from enum to static ID variableRaphael Isemann2019-11-126-13/+28
| | | | | | | | | | | | | | | | 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][NFC] Remove unused ExpressionParser::ParseRaphael Isemann2019-11-042-5/+5
| | | | | | | | | | | | | | | Summary: This function is only used internally by ClangExpressionParser. By putting it in the ExpressionParser class all languages that implement ExpressionParser::Parse have to share the same signature (which forces us in downstream to add swift-specific arguments to ExpressionParser::Parse which then propagate to ClangExpressionParser and so on). Reviewers: davide Subscribers: JDevlieghere, lldb-commits Tags: #upstreaming_lldb_s_downstream_patches, #lldb Differential Revision: https://reviews.llvm.org/D69710
* [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
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-172-9/+8
| | | | | | | | | | | | This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
* Add arm64_32 support to lldb, an ILP32 codegen Jason Molenda2019-10-161-1/+2
| | | | | | | | | | that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
* Set GNUC version in the LLDB expression parser.Adrian Prantl2019-10-111-0/+3
| | | | | | | | This adapts LLDB for https://reviews.llvm.org/D68055. Darwin's libC headers expect the GNUC macro to be set. llvm-svn: 374591
* [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][NFC] Use llvm::all_of instead of std::all_of in CppModuleConfigurationRaphael Isemann2019-10-101-3/+3
| | | | llvm-svn: 374307
* [lldb][NFC] Use unique_ptr in DiagnosticManager to express ownershipRaphael Isemann2019-10-101-5/+6
| | | | llvm-svn: 374289
* [lldb] Don't crash when the ASTImporter produces diagnostics but instead log ↵Raphael Isemann2019-10-091-39/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | them. When playing with the C++ module prototype I noticed I can get LLDB to crash by making a result type that depends on __make_integer_seq (a BuiltinTemplate) which is not supported by the ASTImporter yet. This causes the ASTImporter to emit a diagnostic when copying the type to the ScratchASTContext. As deporting the result type is done after we are done parsing and the Clang's diagnostic engine asserts that it can only be used during parsing, it crashes LLDB while trying to render the diagnostic in the HandleDiagnostic method of ClangDiagnosticManagerAdapter. This patch just moves the HandleDiagnostic call to Clang behind our check that we still have a DiagnosticManager (which we remove after parsing) which prevents the assert from firing. We also shouldn't ignore such diagnostics, so I added a log statement for them. There doesn't seem to way to test this as these diagnostic only happen when we copy a node that's not supported by the ASTImporter which should never happen once we can copy everything with the ASTImporter, so every test case we add here will eventually become invalid. (Note that most of this diff is just whitespace changes as we now use an early exit instead of a huge 'if' block). llvm-svn: 374145
* [lldb] [cmake] Support linking against clang-cpp dylibMichal Gorny2019-10-041-9/+10
| | | | | | | | | Link against clang-cpp dylib rather than split libs when CLANG_LINK_CLANG_DYLIB is enabled. Differential Revision: https://reviews.llvm.org/D68456 llvm-svn: 373734
* [lldb][modern-type-lookup] No longer import temporary declarations into the ↵Raphael Isemann2019-10-041-98/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | persistent AST Summary: As we figured out in D67803, importing declarations from a temporary ASTContext that were originally from a persistent ASTContext causes a bunch of duplicated declarations where we end up having declarations in the target AST that have no associated ASTImporter that can complete them. I haven't figured out how/if we can solve this in the current way we do things in LLDB, but in the modern-type-lookup this is solvable as we have a saner architecture with the ExternalASTMerger. As we can (hopefully) make modern-type-lookup the default mode in the future, I would say we try fixing this issue here. As we don't use the hack that was reinstated in D67803 during modern-type-lookup, the test case for this is essentially just printing any kind of container in `std::` as we would otherwise run into the issue that required a hack like D67803. What this patch is doing in essence is that instead of importing a declaration from a temporary ASTContext, we instead check if the declaration originally came from a persistent ASTContext (e.g. the debug information) and we directly import from there. The ExternalASTMerger is already connected with ASTImporters to these different sources, so this patch is essentially just two parts: 1. Mark our temporary ASTContext/ImporterSource as temporary when we import from the expression AST. 2. If the ExternalASTMerger sees we import from the expression AST, instead of trying to import these temporary declarations, check if we can instead import from the persistent ASTContext that is already connected. This ensures that all records from the persistent source actually come from the persistent source and are minimally imported in a way that allows them to be completed later on in the target AST. The next step is to run the ASTImporter for these temporary expressions with the MinimalImport mode disabled, but that's a follow up patch. This patch fixes most test failures with modern-type-lookup enabled by default (down to 73 failing tests, which includes the 22 import-std-module tests which need special treatment). Reviewers: shafik, martong Reviewed By: martong Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68326 llvm-svn: 373711
* factor out an abstract base class for FileLawrence D'Anna2019-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch factors out File as an abstract base class and moves most of its actual functionality into a subclass called NativeFile. In the next patch, I'm going to be adding subclasses of File that don't necessarily have any connection to actual OS files, so they will not inherit from NativeFile. This patch was split out as a prerequisite for https://reviews.llvm.org/D68188 Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68317 llvm-svn: 373564
* [lldb][NFC] Disallow changing the ASTContext of an ClangASTContext after ↵Raphael Isemann2019-10-012-6/+2
| | | | | | | | | | | construction. We have no use case in LLDB where we actually do want to change the ASTContext after it the ClangASTContext has been constructed. All callers of setASTContext are just setting the ASTContext directly after construction, so we might as well make this a Constructor instead of supporting this tricky use case. llvm-svn: 373330
* [clang][lldb][NFC] Encapsulate ExternalASTMerger::ImporterSourceRaphael Isemann2019-10-013-7/+8
| | | | | | NFC preparation work for upcoming ExternalASTMerger patches. llvm-svn: 373312
* [lldb][NFC][modern-type-lookup] Remove while(false) behind if() {}Raphael Isemann2019-09-301-2/+0
| | | | | | | | This was originally a 'do { ... } while (false);' like in the rest of the function, but the do was refactored into an 'if' without also removing the trailing 'while(false);' llvm-svn: 373206
* remove File::SetStream(), make new files instead.Lawrence D'Anna2019-09-271-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes File::SetStream() and File::SetDescriptor(), and replaces most direct uses of File with pointers to File. Instead of calling SetStream() on a file, we make a new file and replace it. My ultimate goal here is to introduce a new API class SBFile, which has full support for python io.IOStream file objects. These can redirect read() and write() to python code, so lldb::Files will need a way to dispatch those methods. Additionally it will need some form of sharing and assigning files, as a SBFile will be passed in and assigned to the main IO streams of the debugger. In my prototype patch queue, I make File itself copyable and add a secondary class FileOps to manage the sharing and dispatch. In that case SBFile was a unique_ptr<File>. (here: https://github.com/smoofra/llvm-project/tree/files) However in review, Pavel Labath suggested that it be shared_ptr instead. (here: https://reviews.llvm.org/D67793) In order for SBFile to use shared_ptr<File>, everything else should as well. If this patch is accepted, I will make SBFile use a shared_ptr I will remove FileOps from future patches and use subclasses of File instead. Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67891 llvm-svn: 373090
* [lldb][modern-type-lookup] Fix crash when activating modern-type-lookup on LinuxRaphael Isemann2019-09-261-2/+1
| | | | | | | There is no ClangModulesDeclVendor on Linux so that cast is triggering an assert. Let's just remove it as it just casts the type to itself. llvm-svn: 372974
* [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] Use convert_to_slash in CppModuleConfigurationRaphael Isemann2019-09-241-3/+3
| | | | | | That's what we actually want to do. Might fix the Windows bot. llvm-svn: 372729
* [lldb] Decouple importing the std C++ module from the way the program is ↵Raphael Isemann2019-09-246-54/+224
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Ignore generated @import statements in the expression evaluatorRaphael Isemann2019-09-243-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ClangModulesDeclVendor is currently interpreting all injected `@import` statements in our expression wrapper as modules that the user has explicitly requested to be persistently loaded. As we inject `@import` statements with our std module prototype, the ClangModulesDeclVendor will start compiling and loading unrelated C++ modules because it thinks the user has requested that it should load them. As the ClangModulesDeclVendor is lacking the setup to compile these modules (e.g. it lacks the include paths), it will then actually just fail to compile them and cause the whole expression evaluation to fail. This causes these tests to fail on systems that enable the ClangModulesDeclVendor (such as macOS). This patch fixes this by preventing the ClangModulesDeclVendor from interpreting `@import` statements in the wrapper source code. This is done by check if the import happens in the fake source file containing our wrapper code (which implies it was generated by LLDB). This patch doesn't reenable the tests as there is more work needed to get the tests running on macOS (D67760) Reviewers: aprantl, shafik, jingham Subscribers: lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D61565 llvm-svn: 372690
* File::SetDescriptor() should require optionsJonas Devlieghere2019-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | lvm_private::File::GetStream() can fail if m_options == 0 It's not clear from the header a File created with a descriptor will be not be usable by many parts of LLDB unless SetOptions is also called, but it is. This is because those parts of LLDB rely on GetStream() to use the file, and that in turn relies on calling fdopen on the descriptor. When calling fdopen, GetStream relies on m_options to determine the access mode. If m_options has never been set, GetStream() will fail. This patch adds options as a required argument to File::SetDescriptor and the corresponding constructor. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67792 llvm-svn: 372652
* [lldb] Fix that importing decls in a TagDecl end up in wrong declaration ↵Raphael Isemann2019-09-231-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context (partly reverts D61333) Summary: In D61333 we dropped some code from ClangASTSource that checks if imported declarations ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit by the test suite but we didn't have any checks that were affected) and the code seems pointless (as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map). This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests which is currently the most reliable way to test this problem (it's a tricky setup, see description below). Fixes rdar://55502701 and rdar://55129537 -------------------------------------- Some more explanation what is actually going on and what is going wrong: The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map (even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no members. However, `frame var m` works just fine (and fixes all following `expr m` calls). The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST). When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen. This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import the `first` and `second` members as we don't need them for anything). After the expression is done, we take the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members. We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However, P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST). So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first `std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations and just print an empty map as a fallback. The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes the formatters happy as they can now see the members in the DeclContext they are querying. Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this. Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can tell), but that might have unintended side-effects and not sure what's the best way to implement this. Reviewers: friss, martong Reviewed By: martong Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik Tags: #lldb Differential Revision: https://reviews.llvm.org/D67803 llvm-svn: 372549
* [lldb] Print better diagnostics for user expressions and modulesRaphael Isemann2019-09-188-68/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-114-11/+10
| | | | | | | | | 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
* [lldb][NFC] Move Clang-specific flags to ClangUserExpressionRaphael Isemann2019-08-301-0/+17
| | | | | | | | | LLVMUserExpression doesn't use these variables and they are all specific to Clang. Also removes m_const_object as this was actually never used by anyone (and Clang didn't report it as we assigned it in the constructor which seems to count as use). llvm-svn: 370440
* [lldb][NFC] Document options parameter in ClangUserExpression constructorRaphael Isemann2019-08-291-0/+3
| | | | | | Somehow this option was only documented in the swift branch. llvm-svn: 370395
* Revert "[lldb] Move redundant persistent variable counter to ↵Adrian Prantl2019-08-271-10/+0
| | | | | | | | | | | | ClangPersistentVariables" This reverts commit r367842 since it wasn't quite as NFC as advertised and broke Swift support. See https://reviews.llvm.org/D46083 for the rationale behind the original functionality. rdar://problem/54619322 llvm-svn: 370126
* [Symbol] Decouple clang from DeclVendorAlex Langford2019-08-234-3/+47
| | | | | | | | | | Summary: This removes DeclVendor's dependency on clang (and ClangASTContext). DeclVendor has no need to know about specific TypeSystems. Differential Revision: https://reviews.llvm.org/D66628 llvm-svn: 369735
* Fix two compiler warningsPavel Labath2019-08-211-1/+1
| | | | llvm-svn: 369522
* [ClangExpressionParser] Add ClangDeclVendorAlex Langford2019-08-204-11/+57
| | | | | | | | | | | | | | | | Summary: This introduces a layer between DeclVendor and the currently implemented DeclVendors (ClangModulesDeclVendor and AppleObjCDeclVendor). This allows the removal of DeclVendor::GetImporterSource which is extremely clang-specific, freeing up the interface to be more general. A good follow up to this would be to remove the remaining instances of clang in DeclVendor, either by moving things to ClangDeclVendor or by using wrappers (e.g. CompilerDecl instead of clang::NamedDecl). Differential Revision: https://reviews.llvm.org/D66451 llvm-svn: 369424
* [lldb][NFC] Remove unused MaterializeInitializer and MaterializeInternalVariableRaphael Isemann2019-08-172-86/+0
| | | | llvm-svn: 369198
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-142-2/+2
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* Revert "[lldb] Reinstate original guard variable check"Raphael Isemann2019-08-141-5/+9
| | | | | | | | | | | It seems this breaks the following tests: lldb-Suite :: expression_command/call-function/TestCallUserDefinedFunction.py lldb-Suite :: expression_command/rdar42038760/TestScalarURem.py Let's revert this patch and wait until we find an actual issue that could be fixed by also doing the guard variable check on Windows. llvm-svn: 368920
* [lldb] Reinstate original guard variable checkRaphael Isemann2019-08-141-9/+5
| | | | | | | | | | The isGuardVariableSymbol option for ignoring Microsoft's ABI was originally added to get the bots green, but now that we found the actual issue (that we checked for prefix instead of suffix in the MS ABI check), we should be able to properly implement the guard variable check without any strange Microsoft exceptions. llvm-svn: 368802
* [Symbol] Decouple clang from CompilerTypeAlex Langford2019-08-133-4/+10
| | | | | | | | | | Summary: Ideally CompilerType would have no knowledge of clang or any individual TypeSystem. Decoupling clang is relatively straightforward. Differential Revision: https://reviews.llvm.org/D66102 llvm-svn: 368741
* [lldb] Fix Microsoft guard variable detectionRaphael Isemann2019-08-131-1/+1
| | | | | | | Apparently we need to check for a suffix, not a prefix. This broke probably broke expression evaluation on Windows. llvm-svn: 368695
* [lldb] Reland "Refactor guard variable checks in IRForTarget"Raphael Isemann2019-08-131-14/+19
| | | | | | | | It seems the broken guard variable check for Windows was a feature(TM) and not a bug, so let's keep add a flag to the guard check that keeps the old behavior in the places where we ignored guard variables before. llvm-svn: 368688
OpenPOWER on IntegriCloud