summaryrefslogtreecommitdiff
path: root/source/Expression/Materializer.cpp
AgeCommit message (Collapse)Author
2019-08-12[CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.Davide Italiano
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@368620 91177308-0d34-0410-b5e6-96231b3b80d8
2019-08-12[Symbol] GetTypeBitAlign() should return None in case of failure.Davide Italiano
Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@368614 91177308-0d34-0410-b5e6-96231b3b80d8
2019-08-08[Materializer] Remove wrong SetSizeAndAlignmentFromType().Davide Italiano
This function is unused. It's also wrong, because it computes the size and the alignment of the type without asking the runtime, so it doesn't work for any language that has one (e.g. swift). One could consider re-implementing this passing an execution scope context, and modifying GetTypeBitAlign() to do the right thing, but given there are no uses, it's not really useful. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@368249 91177308-0d34-0410-b5e6-96231b3b80d8
2019-07-30[Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford
Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@367360 91177308-0d34-0410-b5e6-96231b3b80d8
2019-07-24[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere
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 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@366936 91177308-0d34-0410-b5e6-96231b3b80d8
2019-07-19[NFC] Remove instances of unused ClangASTContext headerAlex Langford
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@366519 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-11Use std::make_shared in LLDB (NFC)Jonas Devlieghere
Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@353764 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-29Make Type::GetByteSize optional (NFC)Adrian Prantl
This is a continuation of my quest to make the size 0 a supported value. This reapplies r352394 with additional PDB parser fixes prepared by Pavel Labath! Differential Revision: https://reviews.llvm.org/D57273 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@352521 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-28Revert "Make Type::GetByteSize optional (NFC)"Adrian Prantl
This reverts commit r352394 because it broke three windows-specific tests. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@352434 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-28Make Type::GetByteSize optional (NFC)Adrian Prantl
This is a continuation of my quest to make the size 0 a supported value. Differential Revision: https://reviews.llvm.org/D57273 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@352394 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-15Replace auto -> llvm::Optional<uint64_t>Adrian Prantl
This addresses post-commit feedback for https://reviews.llvm.org/D56688 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@351237 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-15Make CompilerType::getBitSize() / getByteSize() return an optional result. NFCAdrian Prantl
The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@351214 91177308-0d34-0410-b5e6-96231b3b80d8
2018-12-15Simplify Boolean expressionsJonas Devlieghere
This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@349215 91177308-0d34-0410-b5e6-96231b3b80d8
2018-11-11Remove header grouping comments.Jonas Devlieghere
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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@346626 91177308-0d34-0410-b5e6-96231b3b80d8
2018-08-07Move RegisterValue,Scalar,State from Core to UtilityPavel Labath
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 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@339127 91177308-0d34-0410-b5e6-96231b3b80d8
2018-04-30Refactor GetNextPersistentVariableName into a non-virtual methodAdrian Prantl
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 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@331235 91177308-0d34-0410-b5e6-96231b3b80d8
2018-04-30Move the persistent variable counter into TargetAdrian Prantl
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 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@331234 91177308-0d34-0410-b5e6-96231b3b80d8
2018-04-30Reflow paragraphs in comments.Adrian Prantl
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 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@331197 91177308-0d34-0410-b5e6-96231b3b80d8
2017-05-12Rename Error -> Status.Zachary Turner
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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@302872 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-03Fix DataExtractor failures.Zachary Turner
Some code that doesn't get compiled on Windows had some references that needed updating, and I missed those. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@296930 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-03Isolate Target-specific functionality of DataExtractor.Zachary Turner
In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@296910 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-03Move Log from Core -> Utility.Zachary Turner
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 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@296909 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-16Don't allow direct access to StreamString's internal buffer.Zachary Turner
This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@287152 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** 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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@280751 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-18Fixed a problem where we failed to get the size of an Objective-C type.Sean Callanan
<rdar://problem/27897056> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@279098 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-08Support floating point values in 128-bit SSE vector registersAdrian Prantl
The System-V x86_64 ABI requires floating point values to be passed in 128-but SSE vector registers (xmm0, ...). When printing such a variable this currently yields an <invalid load address>. This patch makes LLDB's DWARF expression evaluator accept 128-bit registers as scalars. It also relaxes the check that the size of the result of the DWARF expression be equal to the size of the variable to a greater-than. DWARF defers to the ABI how smaller values are being placed in a larger register. Implementation note: I found the code in Value::SetContext() that changes the m_value_type after the fact to be questionable. I added a sanity check that the Value's memory buffer has indeed been written to (this is necessary, because we may have a scalar value in a vector register), but really I feel like this is the wrong place to be setting it. Reviewed by Greg Clayton. http://reviews.llvm.org/D17897 rdar://problem/24944340 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@262947 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-27Revert "Fix bug with register values byte order in expression evaluation."Todd Fiala
This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot. See details in: https://llvm.org/bugs/show_bug.cgi?id=26758 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@262156 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-26Register value is not necessarily scalar.Chaoren Lin
Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@262081 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-26Fix bug with register values byte order in expression evaluation.Aidan Dodds
The evaluation of expressions containing register values was broken for targets for which endianness differs from host. Committed on behalf of: mamai <marianne.mailhot.sarrasin@gmail.com> Differential revision: http://reviews.llvm.org/D17167 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@262041 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-10Fixed a bug where the size of a type was used instead of the size of a pointer.Sean Callanan
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@252655 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-04Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. ↵Jim Ingham
Zero out the Expression ResultVariable so it's in a known initial state. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@252072 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-26Fix Clang-tidy modernize-use-override warnings in some files in source; ↵Eugene Zelenko
other minor fixes. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@251309 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-03Add PersistentVariableDelegate to handle language-specific dematerialization.Sean Callanan
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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@249233 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-02Made GetScratchTypeSystemForLanguage return an error if desired.Sean Callanan
Also made it not store nullptrs in its TypeSystemMap, so it will retry to make the AST context if it errored out last time. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@249167 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-01Eliminated redundant "constructors" for ClangExpressionVariable. ↵Sean Callanan
The ClangExpressionVariable::CreateVariableInList functions looked cute, but caused more confusion than they solved. I removed them, and instead made sure that there are adequate facilities for easily adding newly-constructed ExpressionVariables to lists. I also made some of the constructors that are common be generic, so that it's possible to construct expression variables from generic places (like the ABI and ValueObject) without having to know the specifics about the class. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@249095 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-30Now persistent expression data no longer lives with the Target, but rather withSean Callanan
the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@248934 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-29Removed a bunch of dependencies of Materializer on ClangUserExpression.Sean Callanan
Instead we now just generically use UserExpression. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@248842 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-25Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan
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). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@248612 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-17Removed a needless cast to ClangExpressionVariable.Sean Callanan
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@247910 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-08ExpressionVariable now uses llvm::cast() instead of As...() for RTTI.Sean Callanan
As part of our overall switch from hand-rolling RTTI to using LLVM-compatible methods, I've done the same for ExpressionVariable. The main documentation for how to do this is in TypeSystem.h, so I've simply referred to that. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@247085 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-04This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan
stores information about a variable that different parts of LLDB use, from the compiler-specific portion that only the expression parser cares about. http://reviews.llvm.org/D12602 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@246871 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-03Jim told me about a cleaner way to include headers from plug-ins.Sean Callanan
This is still something I need to fix, but at least it's not so ugly, and it's consistent with the other code that does that so we will catch it when we purge all such code. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@246738 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-03In preparation for factoring persistent variables into a generic part and aSean Callanan
Clang-specific part, create the ExpressionVariable source/header file and move ClangExpressionVariable into the Clang expression parser plugin. It is expected that there are some ugly #include paths... these will be resolved by either (1) making that code use generic expression variables (once they're separated appropriately) or (2) moving that code into a plug-in, often the expression parser plug-in. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@246737 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-24Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton
lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@245905 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-11ClangASTType is now CompilerType.Greg Clayton
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@244689 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-25Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton
A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@240702 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-03Don't #include ClangPersistentVariables.h from Process.hZachary Turner
Nothing from this header file was even being referenced in Process.h anyway, so it was a completely unnecessary include. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@231131 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28Preparatory infrastructural work to support dynamically determining sizes of ↵Enrico Granata
ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@227274 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-11Fix some typos:Sylvestre Ledru
* transfered => transferred * unkown => unknown * sucessfully => successfully git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@215367 91177308-0d34-0410-b5e6-96231b3b80d8