summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Language
Commit message (Collapse)AuthorAgeFilesLines
...
* Make the ObjCLanguageRuntimes comply with llvm-style RTTIEnrico Granata2015-09-231-1/+1
| | | | llvm-svn: 248427
* TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton2015-09-172-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &Class::GetClangASTContext()" functions. This cleans up type systems to be more pluggable. Prior to this we had issues: - Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()" - Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem - Cleaned up Module so that it no longer has dedicated type system member variables: lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module. lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module. Now we have a type system map: typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap; TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module - Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract: class CompilerType { ... //---------------------------------------------------------------------- // Return a new CompilerType that is a L value reference to this type if // this type is valid and the type system supports L value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetLValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType that is a R value reference to this type if // this type is valid and the type system supports R value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetRValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a const modifier to this type if // this type is valid and the type system supports const modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddConstModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a volatile modifier to this type if // this type is valid and the type system supports volatile modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddVolatileModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a restrict modifier to this type if // this type is valid and the type system supports restrict modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddRestrictModifier () const; //---------------------------------------------------------------------- // Create a typedef to this type using "name" as the name of the typedef // this type is valid and the type system supports typedefs, else return // an invalid type. //---------------------------------------------------------------------- CompilerType CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const; }; Other changes include: - Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);" - Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed llvm-svn: 247953
* Move hardcoded formatters from the FormatManager to the Language pluginsEnrico Granata2015-09-162-0/+79
| | | | llvm-svn: 247831
* Teach the ObjC data formatters to use the correct language when printing stringsEnrico Granata2015-09-151-0/+7
| | | | llvm-svn: 247727
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-152-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
* Fix CMake build.Chaoren Lin2015-09-142-0/+2
| | | | | | | - Typo: Coca.cpp -> Cocoa.cpp - Missing include. llvm-svn: 247628
* Move Objective-C data formatters to the Objective-C language plugin where ↵Enrico Granata2015-09-1413-0/+4514
| | | | | | they belong llvm-svn: 247627
* Introduce the notion of an escape helper. Different languages have different ↵Enrico Granata2015-09-092-20/+20
| | | | | | | | notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is provided to LLDB This is NFC, other than a code re-org llvm-svn: 247200
* Preparatory work for letting language plugins help the StringPrinter with ↵Enrico Granata2015-09-092-12/+12
| | | | | | formatting special characters llvm-svn: 247189
* Data formatter candidate matches can be generated in a number of ways; ↵Enrico Granata2015-09-092-3/+43
| | | | | | | | | | language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
* Fix Makefile buildKeno Fischer2015-09-053-0/+42
| | | | llvm-svn: 246932
* Never mind, I see what the problem is on the Windows build. Attempt a fixEnrico Granata2015-09-041-1/+0
| | | | llvm-svn: 246876
* Move the C++ data formatters to the C++ language pluginEnrico Granata2015-09-0414-3/+2854
| | | | llvm-svn: 246873
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-033-6/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Fix ObjCLanguage::MethodName::GetCategory after r246616; I was just moving ↵Jim Ingham2015-09-031-1/+1
| | | | | | things around too fast... llvm-svn: 246736
* Move more functionality from the LanguageRuntimes to the Languages.Jim Ingham2015-09-024-0/+854
| | | | llvm-svn: 246616
* Use Language::LanguageIsCPlusPlus instead of doing the same switch over languageEnrico Granata2015-09-021-10/+3
| | | | llvm-svn: 246613
* Add support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-011-0/+1
| | | | | | | | | | | | | | | | | Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
* Revert "Add support for language plugins to provide data formatters"Pavel Labath2015-09-011-1/+0
| | | | | | This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests. llvm-svn: 246536
* And of course, typosEnrico Granata2015-09-011-1/+1
| | | | llvm-svn: 246519
* Attempt at fixing the CMake buildEnrico Granata2015-09-011-0/+1
| | | | llvm-svn: 246518
* Fixup one of the CMakeListsEnrico Granata2015-08-271-2/+2
| | | | llvm-svn: 246220
* Add a new type of plugin: Language pluginEnrico Granata2015-08-2710-0/+413
The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++ llvm-svn: 246212
OpenPOWER on IntegriCloud