summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/FormatManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-3/+2
| | | | | | | | | | | | | | | 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 llvm-svn: 287152
* Make lldb::Regex use StringRef.Zachary Turner2016-09-211-2/+2
| | | | | | | | | | This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1036/+920
| | | | | | | | | | | | | | | | | | | | | | | *** 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. llvm-svn: 280751
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-18/+18
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Fix a bug where language categories would hold on to their caches even after ↵Enrico Granata2015-12-151-4/+16
| | | | | | changes llvm-svn: 255603
* Reapply r253423 and r253424 (which cleanup the data formatters iteration ↵Enrico Granata2015-11-181-15/+0
| | | | | | model, as well as the type X list commands), along with a change by Zachary Turner to bypass a MSVC bug with SFINAE llvm-svn: 253493
* Revert 2 commits breaking the MSVC buildTamas Berghammer2015-11-181-0/+15
| | | | | | | | | | Revert "Remove a few vestigial typedefs from the old world" This reverts commit 05872cda2a00fbd988c4fc761b1f87fe9edce224. Revert "Cleanup the type X list commands to use the new ForEach goodness" This reverts commit 85b1d83819a22cdc9ef12f58fd4fa92b473a4f81. llvm-svn: 253455
* Cleanup the type X list commands to use the new ForEach goodnessEnrico Granata2015-11-181-15/+0
| | | | llvm-svn: 253423
* The existing logic to loop over formatters is very pre-C++11, using void* ↵Enrico Granata2015-11-141-0/+15
| | | | | | | | | batons, and function pointers, and raw memory allocations instead of safer more modern constructs This is a first pass at a cleanup of that code, modernizing the "type X clear" commands, and providing the basic infrastructure I plan to use all over More cleanup will come over the next few days llvm-svn: 253125
* Extend the TypeSystem's ShouldPrintAsOneLiner implementation so that the ↵Enrico Granata2015-11-091-1/+18
| | | | | | ValueObject itself also gets a say in the process; NFC llvm-svn: 252516
* Rationalization of includes in the data formatters codeEnrico Granata2015-10-201-4/+3
| | | | llvm-svn: 250798
* Introduce the concept of a type that is meaningless without dynamic ↵Enrico Granata2015-10-201-18/+12
| | | | | | | | resolution, which are essentially placeholder types meant to appease a language's type system but do not offer any actual information to the debugger, unless further resolved This is currently meant for data formatters to know to ignore such types in caching and lookup llvm-svn: 250767
* Resubmit: RenderScript command for printing allocation contents Ewan Crawford2015-10-161-0/+2
| | | | | | | | | Previous commit r250281 broke TestDataFormatterSmartArray.py Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager. Differential Revision: http://reviews.llvm.org/D13730 llvm-svn: 250499
* Create a logging category that is specific to data formatters activityEnrico Granata2015-10-061-4/+4
| | | | llvm-svn: 249433
* Introduce a FormattersMatchData class which contains all the information ↵Enrico Granata2015-10-061-68/+60
| | | | | | | | that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
* Fix covered-switch-default warning in FormatManager.Bruce Mitchener2015-09-231-1/+0
| | | | | | | | | | | | | | | | Summary: The default case doesn't need to be here as the switch covers all possible values. If there's a new "lazy bool" value added in the future, the compiler would start to warn about the new case not being covered. Reviewers: granata.enrico, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13084 llvm-svn: 248365
* Allow CompilerType to express a vote on whether oneliner printing should happenEnrico Granata2015-09-231-0/+17
| | | | llvm-svn: 248363
* Add {TypeSystem|CompilerType}::GetTypeForFormatters()Enrico Granata2015-09-231-1/+1
| | | | | | | | | Different type system may have different notions of attributes of a type that do not matter for data formatters matching purposes For instance, in the case of clang types, we remove some qualifiers (e.g. "volatile") as it doesn't make much sense to differentiate volatile T from T in the data formatters This new API allows each type system to generate, if needed, a type that does not have those unwanted attributes that the data formatters can then consume to generate matches llvm-svn: 248359
* TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton2015-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &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
* DataFormatters: Rename clang_type to compiler_type.Bruce Mitchener2015-09-171-15/+15
| | | | | | | | | | Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
* Add the ability for formatter categories to be bound to one or more languagesEnrico Granata2015-09-171-2/+2
| | | | | | What that does is it restricts formatters in those categories to only match to types coming from "compatible" source languages llvm-svn: 247872
* Move hardcoded formatters from the FormatManager to the Language pluginsEnrico Granata2015-09-161-91/+41
| | | | llvm-svn: 247831
* Move Objective-C data formatters to the Objective-C language plugin where ↵Enrico Granata2015-09-141-314/+6
| | | | | | they belong llvm-svn: 247627
* Introduce the notion of an escape helper. Different languages have different ↵Enrico Granata2015-09-091-0/+6
| | | | | | | | 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
* Data formatter candidate matches can be generated in a number of ways; ↵Enrico Granata2015-09-091-31/+12
| | | | | | | | | | 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
* Move the C++ data formatters to the C++ language pluginEnrico Granata2015-09-041-186/+34
| | | | llvm-svn: 246873
* Nuke CXXFormatterFunctions.cpp - split the contents of it across different ↵Enrico Granata2015-09-041-2/+9
| | | | | | | | files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
* Move the functions that FormatManager uses to actually load formatters into ↵Enrico Granata2015-09-021-99/+2
| | | | | | | | their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
* std::initializer_list is not safe to return from a function, as copies are ↵Enrico Granata2015-09-011-1/+1
| | | | | | not guaranteed to extend the lifetime of the underlying storage llvm-svn: 246597
* Add support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-011-12/+143
| | | | | | | | | | | | | | | | | 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-134/+16
| | | | | | This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests. llvm-svn: 246536
* Add support for language plugins to provide data formattersEnrico Granata2015-09-011-16/+134
| | | | | | | | | | | | | | | | | 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: 246515
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-4/+4
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 245905
* ClangASTType is now CompilerType.Greg Clayton2015-08-111-8/+8
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* First step in getting LLDB ready to support multiple different type systems.Greg Clayton2015-08-111-2/+2
| | | | | | | | This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system. All tests pass on MacOSX and passed on linux the last time this was submitted. llvm-svn: 244679
* There is no reason why this formatter should not cascade. Make it cascadeEnrico Granata2015-07-281-1/+1
| | | | llvm-svn: 243369
* Add a summary for vector typesEnrico Granata2015-07-071-0/+20
| | | | | | | | | | | | The summary is - quite simply - a one-line printout of the vector elements We still need synthetic children: a) as a source of the elements to print in the summary b) for graphical IDEs that display structure regardless of the summary settings rdar://5429347 llvm-svn: 241531
* When I introduced hard-coded formatters, I made them non-cacheableEnrico Granata2015-07-011-5/+9
| | | | | | | | | This is because - in theory - the formatter could match on not just the type, but also other properties of a ValueObject, so a per-type caching would not be a good thing On the other hand, that is not always true - sometimes the matching truly is per-type So, introduce a non-cacheable attribute on formatters that decides whether a formatter should or should not be cached. That way, the few formatters that don't want themselves cached can do so, but most formatters (including most hard-coded ones) can cache themselves just fine llvm-svn: 241184
* Add a formatter for wchar_t[N] arraysEnrico Granata2015-06-151-7/+12
| | | | | | rdar://21299888 llvm-svn: 239777
* Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath2015-06-081-2/+2
| | | | | | This seems to break expression evaluation on the linux build. llvm-svn: 239366
* Introduce a TypeSystem interface to support adding non-clang languages.Pavel Labath2015-06-081-2/+2
| | | | | | | | | | | | | Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8712 Original Author: Ryan Brown <ribrdb@google.com> llvm-svn: 239360
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Remove unused #includes of ScriptInterpreterPython.hZachary Turner2015-05-281-1/+0
| | | | llvm-svn: 238470
* A few improvements to our vector types formatting story:Enrico Granata2015-03-061-11/+15
| | | | | | | | | - use a hardcoded formatter to match all vector types, and make it so that their element type is taken into account when doing default formatting - special case a vector of char to display byte values instead of characters by default Fixes the test failures Ilia was seeing llvm-svn: 231504
* Provide synthetic children for some vector typesEnrico Granata2015-03-061-0/+9
| | | | | | | | | | Unlike GDB, we tackle the problem of representing vector types in different styles by having a synthetic child provider that recognizes the format you're trying to apply to the variable, and coming up with the right type and number of child values to match that format This makes for a more compact representation and less visual noise Fixes rdar://5429347 llvm-svn: 231449
* Add missing check for LLDB_DISABLE_PYTHON in FormatManagerTamas Berghammer2015-02-111-0/+2
| | | | llvm-svn: 228856
* Fix a couple typos in the previous commitEnrico Granata2015-02-101-0/+1
| | | | llvm-svn: 228762
* Add an LLDB summary for CMTime. Fixes rdar://15370376Enrico Granata2015-02-101-0/+19
| | | | llvm-svn: 228759
* Harden against the process pointer being null - this seems like it shouldn't ↵Enrico Granata2015-01-281-0/+2
| | | | | | | | happen, except it did - by a user stopping the debugger while the variables view was refreshing Fixes rdar://19599357 llvm-svn: 227350
* Remove the last vestige of the world before data formatters :-)Enrico Granata2014-12-101-0/+11
| | | | | | | | Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem This patch transitions that code into a hardcoded summary llvm-svn: 223906
OpenPOWER on IntegriCloud