summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression
Commit message (Collapse)AuthorAgeFilesLines
...
* [PDB] Support PDB-backed expressions evaluation (+ fix stuck test)Aleksandr Urakov2018-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch contains several small fixes, which makes it possible to evaluate expressions on Windows using information from PDB. The changes are: - several sanitize checks; - make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic value on a failure, because callers wait 0 in this case; - entry point required to be a file address, not RVA, in the ObjectFilePECOFF; - do not crash on a debuggee second chance exception - it may be an expression evaluation crash. Also fix detection of "crushed" threads in tests; - create parameter declarations for functions in AST to make it possible to call debugee functions from expressions; - relax name searching rules for variables, functions, namespaces and types. Now it works just like in the DWARF plugin; - fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc. Reviewers: zturner, asmith, stella.stamenova Reviewed By: stella.stamenova, asmith Tags: #lldb Differential Revision: https://reviews.llvm.org/D53759 llvm-svn: 348136
* Revert "[PDB] Support PDB-backed expressions evaluation"Stella Stamenova2018-11-301-1/+1
| | | | | | | | | This reverts commit dec87759523b2f22fcff3325bc2cd543e4cda0e7. This commit caused the tests on Windows to run forever rather than complete. Reverting until the commit can be fixed to not stall. llvm-svn: 348009
* [PDB] Support PDB-backed expressions evaluationAleksandr Urakov2018-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch contains several small fixes, which makes it possible to evaluate expressions on Windows using information from PDB. The changes are: - several sanitize checks; - make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic value on a failure, because callers wait 0 in this case; - entry point required to be a file address, not RVA, in the ObjectFilePECOFF; - do not crash on a debuggee second chance exception - it may be an expression evaluation crash; - create parameter declarations for functions in AST to make it possible to call debugee functions from expressions; - relax name searching rules for variables, functions, namespaces and types. Now it works just like in the DWARF plugin; - fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc. Reviewers: zturner, asmith, stella.stamenova Reviewed By: stella.stamenova, asmith Tags: #lldb Differential Revision: https://reviews.llvm.org/D53759 llvm-svn: 347962
* Remove header grouping comments.Jonas Devlieghere2018-11-117-23/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* [FileSystem] Open File instances through the FileSystem.Jonas Devlieghere2018-11-021-5/+6
| | | | | | | | | | | This patch modifies how we open File instances in LLDB. Rather than passing a path or FileSpec to the constructor, we now go through the virtual file system. This is needed in order to make things work with the VFS in the future. Differential revision: https://reviews.llvm.org/D54020 llvm-svn: 346049
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-2/+2
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner2018-10-251-2/+3
| | | | | | | | | | This is similar to D53597, but following up with 2 more enums. After this, all flag enums should be strongly typed all the way through to the symbol files plugins. Differential Revision: https://reviews.llvm.org/D53616 llvm-svn: 345314
* [LLDB] - Parse the DW_LLE_startx_length correctly for DWARF v5 case.George Rimar2018-10-251-2/+6
| | | | | | | | | | | | | | | | | | | | | Currently, we always parse the length field of DW_LLE_startx_length entry as U32. That is correct for pre-standard definition: https://gcc.gnu.org/wiki/DebugFission - "A start/length entry contains one unsigned LEB128 number and a 4-byte unsigned value (as would be represented by the form code DW_FORM_const4u). The first number is an index into the .debug_addr section that selects the beginning offset, and the second number is the length of the range. ") But DWARF v5 says: "This is a form of bounded location description that has two unsigned ULEB operands. The first value is an address index (into the .debug_addr section) that indicates the beginning of the address range over which the location is valid. The second value is the length of the range." Fortunately, we can easily handle the difference. No test case because it seems impossible to test until we will be ready to use DWARF v5 in tests that need to run the executables. Differential revision: https://reviews.llvm.org/D53646 llvm-svn: 345249
* [LLDB] - Implement the support for the .debug_loclists section.George Rimar2018-10-232-0/+15
| | | | | | | | | | | This implements the support for .debug_loclists section, which is DWARF 5 version of .debug_loc. Currently, clang is able to emit it with the use of D53365. Differential revision: https://reviews.llvm.org/D53436 llvm-svn: 345016
* Revert "Return a named error in the result object of an expression with no ↵Krasimir Georgiev2018-10-183-9/+4
| | | | | | | | | | | | | | | | | result" This reverts commit r344647. This causes build failures with [-Werror, -Wswitch]. Some cases where the newly introduced enum value is not handled in particular are in: lldb/source/Expression/REPL.cpp:350 lldb/source/Interpreter/CommandInterpreter.cpp:1529 (maybe there could be more) As I don't understand lldb to make sure the likely trivial fixes are correct and also as they might need additional tests, leaving to the author to resolve. llvm-svn: 344722
* Return a named error in the result object of an expression with no resultJim Ingham2018-10-163-4/+9
| | | | | | | | | | | | Before we returned an error that was not exposed in the SB API and no useful error message. This change returns eExpressionProducedNoResult and an appropriate error string. <rdar://problem/44539514> Differential Revision: https://reviews.llvm.org/D53309 llvm-svn: 344647
* Revert "[IRInterpreter] Minor cleanups, add comments. NFCI."Davide Italiano2018-09-171-3/+7
| | | | | | This breaks buildbots. llvm-svn: 342404
* [IRInterpreter] Minor cleanups, add comments. NFCI.Davide Italiano2018-09-141-7/+3
| | | | llvm-svn: 342280
* [IRInterpreter] Fall back to JIT with 128-bit values.Davide Italiano2018-09-141-0/+12
| | | | | | | | | | | | | They're not that common, and falling back is definitely better than throwing an error instead of the result. If we feel motivated, we might end up implementing support for these, but it's unclear whether it's worth the effort/complexity. Fixes PR38925. <rdar://problem/44436068> llvm-svn: 342262
* Add support for descriptions with command completions.Raphael Isemann2018-09-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
* [DWARFExpression] Read literars as unsigned values.Jonas Devlieghere2018-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | After landing r341457, we started seeing a failure on the swift-lldb bots. The change was correct and pretty straightforward, a DW_OP_constu was replaced with DW_OP_lit23, the value remaining identical. 0x000000f4: DW_TAG_variable DW_AT_location (0x00000000 [0x0000000100000a51, 0x0000000100000d47): DW_OP_lit23, DW_OP_stack_value) DW_AT_name ("number") However, this broke LLDB. (Int) number = <extracting data from value failed> The value was read correctly, but apparently the value's type was different. When reading a constu it was reading a uint64 (m_type = e_ulonglong) while for the literal, it got a signed int (m_type = e_sint). This change makes sure we read the value as an unsigned. Differential revision: https://reviews.llvm.org/D51730 llvm-svn: 342142
* Allow IRInterpreter to deal with non-power-of-2 sized types to support some ↵Frederic Riss2018-08-281-11/+6
| | | | | | | | | | | | | | | | | | | | bitfield accesses. Summary: For some bitfield patterns (like the one added by this commit), Clang will generate non-regular data types like i24 or i48. This patch follows a pretty naive approach of just bumping the type size to the next power of 2. DataExtractor know how to deal with weird sizes. The operations on Scalar do not know how to deal with those types though, so we have to legalize the size when creating a Scalar. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D51245 llvm-svn: 340880
* [IRMemoryMap] Shrink Allocation and make it move-only (NFC)Vedant Kumar2018-08-081-5/+6
| | | | | | | | | | | | | | | | | Profiling data show that Allocation::operator= is hot (see the data attached to the Phab review). Reorder a few fields within Allocation to avoid implicit structure padding and shrink the structure. This should make copies a bit cheaper. Also, given that an Allocation contains a std::vector (by way of DataBufferHeap), it's preferable to make it move-only instead of permitting expensive copies. As an added benefit this allows us to have a single Allocation constructor instead of two. Differential Revision: https://reviews.llvm.org/D50271 llvm-svn: 339290
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-075-6/+6
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* [IRMemoryMap] Avoid redundant zero-init in the Allocation constructor (NFC)Vedant Kumar2018-08-061-5/+1
| | | | | | | In the lldb-bench/arithmetic benchmark, 1.7% of the total running time is spent zero-initializing a std::vector that has already been zeroed. llvm-svn: 339051
* Fix whitespace formatting in DWARFExpression::DumpLocationPavel Labath2018-07-191-14/+14
| | | | | | | | we were printing an extra space before the start for the expression and an extra space after some dwarf operators. This makes sure we only print exactly one space **between** operators and nowhere else. llvm-svn: 337452
* Add a way to load an image using a library name and list of paths.Jim Ingham2018-06-281-1/+5
| | | | | | | | | | This provides an efficient (at least on Posix platforms) way to offload to the target process the search & loading of a library when all we have are the library name and a set of potential candidate locations. <rdar://problem/40905971> llvm-svn: 335912
* Fix an issue where DW_OP_deref might be dereferencing a file address. ↵Greg Clayton2018-06-211-0/+28
| | | | | | | | Convert the file address to a load address so this works. https://bugs.llvm.org/show_bug.cgi?id=36871 llvm-svn: 335263
* IRInterpreter: fix sign extension of small types (pr37840)Pavel Labath2018-06-201-7/+1
| | | | | | | | | | | | | Sign-extension of small types (e.g. short) was not handled correctly. The reason for that was that when we were assigning the a value to the Scalar object, we would accidentally promote the type to int (even though the assignment code in AssignTypeToMatch tried to cast the value to the appropriate type, it would still invoke the "int" version of operator=). Instead, I use the APInt version of operator=, where the bitwidth is specified explicitly. Among other things, this allows us to fold the individual size cases into one. llvm-svn: 335114
* Replace HostInfo::GetLLDBPath with specific functionsPavel Labath2018-06-191-4/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Instead of a function taking an enum value determining which path to return, we now have a suite of functions, each returning a single path kind. This makes it easy to move the python-path function into a specific plugin in a follow-up commit. All the users of GetLLDBPath were converted to call specific functions instead. Most of them were hard-coding the enum value anyway, so this conversion was simple. The only exception was SBHostOS, which I've changed to use a switch on the incoming enum value. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48272 llvm-svn: 335052
* [IRMemoryMap] Fix the alignment adjustment in MallocVedant Kumar2018-05-311-6/+12
| | | | | | | | | | | | | | | | | | | | This prevents Malloc from allocating the same chunk of memory twice, as a byproduct of an alignment adjustment which gave the client access to unallocated memory. Prior to this patch, the newly-added test failed with: $ lldb-test ir-memory-map ... ir-memory-map-overlap1.test ... Command: malloc(size=64, alignment=32) Malloc: address = 0x1000cd080 Command: malloc(size=64, alignment=8) Malloc: address = 0x1000cd0b0 Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0) Differential Revision: https://reviews.llvm.org/D47551 llvm-svn: 333697
* Set m_struct_valid to initial value in ctor. Jason Molenda2018-05-311-1/+2
| | | | | | | | Patch from Tom Tromey <ttromey@mozilla.com>. Differential Revision: https://reviews.llvm.org/D47481 llvm-svn: 333690
* Typo fixes.Bruce Mitchener2018-05-291-1/+1
| | | | | | | | | | Reviewers: javed.absar Subscribers: ki.stfu, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D47421 llvm-svn: 333399
* Break dependency from Core to ObjectFileJIT.Zachary Turner2018-05-232-11/+16
| | | | | | | | | | | | | | | | | | The only reason this was here was so that Module could have a function called CreateJITModule which created things in a special order. Instead of making this specific to creating JIT modules, I converted this into a template function that can create a module for any type of object file plugin and just forwards arguments through. Since the template is not instantiated in Core, the linker (and header file) dependency moves to the point where it is instantiated, which only happens in Expression. Conceptually, this location also makes more sense for a dependency on ObjectFileJIT. After all, we JIT expressions so it's no surprise that Expression needs to make use of ObjectFileJIT. Differential Revision: https://reviews.llvm.org/D47228 llvm-svn: 333143
* DWARFExpression: Convert file addresses to load addresses early on.Adrian Prantl2018-05-031-0/+6
| | | | | | | | | | | | | | | | | | This is a change that only affects Swift and is NFC for the language plugins on llvm.org. In Swift, we can have global variables with a location such as DW_OP_addr <addr> DW_OP_deref. The DWARF expression evaluator doesn't know how to apply a DW_OP_deref to a file address, but at the very end we convert the file address into a load address. This patch moves the file->load address conversion to right after the result of the DW_OP_addr is pushed onto the stack so that a subsequent DW_OP_deref (and potentially other operations) can be interpreted. rdar://problem/39767528 Differential revision: https://reviews.llvm.org/D46362 llvm-svn: 331492
* Revert "DWARFExpression: Convert file addresses to load addresses early on."Adrian Prantl2018-05-031-4/+1
| | | | | | This reverts commit 331462 while investigating bot breakage. llvm-svn: 331480
* DWARFExpression: Convert file addresses to load addresses early on.Adrian Prantl2018-05-031-1/+4
| | | | | | | | | | | | | | | | | | This is a change that only affects Swift and is NFC for the language plugins on llvm.org. In Swift, we can have global variables with a location such as DW_OP_addr <addr> DW_OP_deref. The DWARF expression evaluator doesn't know how to apply a DW_OP_deref to a file address, but at the very end we convert the file address into a load address. This patch moves the file->load address conversion to right after the result of the DW_OP_addr is pushed onto the stack so that a subsequent DW_OP_deref (and potentially other operations) can be interpreted. rdar://problem/39767528 Differential revision: https://reviews.llvm.org/D46362 llvm-svn: 331462
* Enable AUTOBRIEF in doxygen configuration.Adrian Prantl2018-05-021-13/+13
| | | | | | | | | | | | | | This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments. This patch also reflows the paragraphs in all doxygen comments. See also https://reviews.llvm.org/D46290. Differential Revision: https://reviews.llvm.org/D46321 llvm-svn: 331373
* Refactor GetNextPersistentVariableName into a non-virtual methodAdrian Prantl2018-04-302-1/+13
| | | | | | | | | | | | 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-3/+4
| | | | | | | | | | | | | | | | | 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-3012-230/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support reading section ".gnu_debugaltlink"Jan Kratochvil2018-04-291-0/+1
| | | | | | Differential revision: https://reviews.llvm.org/D40468 llvm-svn: 331148
* Move the codebase to use: DWARFCompileUnit -> DWARFUnitJan Kratochvil2018-03-181-10/+10
| | | | | | | | | | | | Now the codebase can use the DWARFUnit superclass. It will make it later seamlessly work also with DWARFPartialUnit for DWZ. This patch is only a search-and-replace easily undone, nothing interesting in it. Differential revision: https://reviews.llvm.org/D42892 llvm-svn: 327810
* [IRExecutionUnit] Remove broken/dead code.Davide Italiano2018-01-041-26/+2
| | | | llvm-svn: 321833
* Do not use default arguments of DataLayout::getPointer*. NFCFangrui Song2017-12-061-5/+0
| | | | | | | | | | | | | | Summary: There are "FIXME"s in include/llvm/IR/DataLayout.h to remove the default arguments. Reviewers: zturner, clayborg Reviewed By: zturner Subscribers: bjope Differential Revision: https://reviews.llvm.org/D40064 llvm-svn: 319869
* Revert "[lldb] Use OrcMCJITReplacement rather than MCJIT as the underlying ↵Pavel Labath2017-11-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JIT for LLDB" This commit really did not introduce any functional changes (for most people) but it turns out it's not for the reason we thought it was. The reason wasn't that Orc is a perfect drop-in replacement for MCJIT, but it was because we were never using Orc in the first place, as it was not initialized. Orc's initialization relies on a global constructor in the LLVMOrcJIT.a. Since this archive does not expose any symbols referenced from other object files, it does not get linked into liblldb when linking against llvm components statically. However, in an LLVM_LINK_LLVM_DYLIB=On build, LLVMOrcJit.a is linked into libLLVM.so using --whole-archive, so the global constructor does end up firing. The result of using Orc jit is pr34194, where lldb fails to evaluate even very simple expressions. This bug can be reproduced in non-LLVM_LINK_LLVM_DYLIB builds by making sure Orc jit is linked into liblldb, for example by #including llvm/ExecutionEngine/OrcMCJITReplacement.h in IRExecutionUnit.cpp (and adding OrcJIT as a dependency to the relevant CMakeLists.txt file). The bug reproduces (at least) on linux and osx. The root cause of the bug seems to be related to relocation processing. It seems Orc processes relocations earlier than the system it is replacing. This means the relocation processing happens before we have had a chance to remap section load addresses to reflect their address in the target process memory, so they end up pointing to locations in the lldb's address space instead. I am not sure whether this is a bug in Orc jit, or in how we are using it from lldb, but in any case it is preventing us from using Orc right now. Reverting this fixes LLVM_LINK_LLVM_DYLIB build, and makes it clear that we are in fact *not* using Orc, and we never really were. This reverts commit r279327. llvm-svn: 318039
* Add support for the DWP debug info formatTamas Berghammer2017-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: The DWP (DWARF package) format is used to pack multiple dwo files generated by split-dwarf into a single ELF file to make distributing them easier. It is part of the DWARFv5 spec and can be generated by dwp or llvm-dwp from a set of dwo files. Caviats: * Only the new version of the dwp format is supported (v2 in GNU numbering schema and v5 in the DWARF spec). The old version (v1) is already deprecated but binutils 2.24 still generates that one. * Combining DWP files with module debugging is not yet supported. Subscribers: emaste, mgorny, aprantl Differential Revision: https://reviews.llvm.org/D36062 llvm-svn: 311775
* Remove the DWARFExpression -> Clang ExpressionParser dependencyTamas Berghammer2017-08-161-21/+14
| | | | | | | | It was completly unused and broke the part of the encapsulation that common code shouldn't depend on specific plugins or language specific features. llvm-svn: 311000
* Update for llvm api change.Rafael Espindola2017-08-031-5/+0
| | | | llvm-svn: 309916
* Rename Error -> Status.Zachary Turner2017-05-1211-127/+128
| | | | | | | | | | | | | | | 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
* Add CopyDiagnostic to the DiagnosticManager.Jim Ingham2017-04-191-0/+9
| | | | | | | | From Gregor Milos (gmilos@apple.com), for: https://reviews.llvm.org/D32078 llvm-svn: 300733
* Revert r298776 - Expression: add missing linkage to RuntimeDyld ...Michal Gorny2017-03-301-1/+0
| | | | | | This needs to be addressed within LLVM itself. llvm-svn: 299095
* Expression: add missing linkage to RuntimeDyld componentMichal Gorny2017-03-251-0/+1
| | | | | | | | | | | Add missing linkage from lldbExpression library to LLVMRuntimeDyld. Otherwise the build against shared LLVM libraries fails with: lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):IRExecutionUnit.cpp:function llvm::RTDyldMemoryManager::deregisterEHFrames(unsigned char*, unsigned long, unsigned long): error: undefined reference to 'llvm::RTDyldMemoryManager::deregisterEHFramesInProcess(unsigned char*, unsigned long)' Differential Revision: https://reviews.llvm.org/D31367 llvm-svn: 298776
* Fix warnings from clang build on macOS.Bruce Mitchener2017-03-231-1/+2
| | | | | | | | | | Reviewers: lldb-commits Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31279 llvm-svn: 298585
* Initialize m_allow_cxx, m_allow_objc. These ivars in the base class are not Jason Molenda2017-03-211-0/+2
| | | | | | | | | initialized in the ctor and they're only initialized to 'true' in ClangUserExpression.cpp when specific languages are detected so we can use uninitialized values. This bug has been present since the ivars were added in r144042. <rdar://problem/31105864> llvm-svn: 298333
OpenPOWER on IntegriCloud