Fix covered-switch-default warning in FormatManager.

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 futur

Fix covered-switch-default warning in FormatManager.

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

show more ...

Allow CompilerType to express a vote on whether oneliner printing should happen

llvm-svn: 248363

Add {TypeSystem|CompilerType}::GetTypeForFormatters()

Different type system may have different notions of attributes of a type that do not matter for data formatters matching purposes
For instance,

Add {TypeSystem|CompilerType}::GetTypeForFormatters()

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

show more ...

TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.

This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module

TypeSystem is now a plugin interface and removed any "ClangASTContext &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

show more ...

DataFormatters: Rename clang_type to compiler_type.

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 languages

What that does is it restricts formatters in those categories to only match to types coming from "compatible" source lan

Add the ability for formatter categories to be bound to one or more languages

What that does is it restricts formatters in those categories to only match to types coming from "compatible" source languages

llvm-svn: 247872

show more ...

Move hardcoded formatters from the FormatManager to the Language plugins

llvm-svn: 247831

Move Objective-C data formatters to the Objective-C language plugin where they belong

llvm-svn: 247627

Introduce the notion of an escape helper. Different languages have different notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is prov

Introduce the notion of an escape helper. Different languages have different 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

show more ...

Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is

Data formatter candidate matches can be generated in a number of ways; 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

show more ...

Move the C++ data formatters to the C++ language plugin

llvm-svn: 246873

Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line

This is preparatory work for moving these formatters int

Nuke CXXFormatterFunctions.cpp - split the contents of it across different 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

show more ...

Move the functions that FormatManager uses to actually load formatters into their own file

These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going

Move the functions that FormatManager uses to actually load formatters into 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

show more ...

std::initializer_list is not safe to return from a function, as copies are not guaranteed to extend the lifetime of the underlying storage

llvm-svn: 246597

Add support for language plugins to provide data formatters (second attempt)

Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be

Add support for language plugins to provide data formatters (second attempt)

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

show more ...

Revert "Add support for language plugins to provide data formatters"

This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests.

llvm-svn: 246536

Add support for language plugins to provide data formatters

Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when

Add support for language plugins to provide data formatters

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

show more ...

Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions.

Create a new "lldb_

Final bit of type system cleanup that abstracts declaration contexts into 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

show more ...

ClangASTType is now CompilerType.

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.

This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types

First step in getting LLDB ready to support multiple different type systems.

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

show more ...

There is no reason why this formatter should not cascade. Make it cascade

llvm-svn: 243369

Add a summary for vector types

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)

Add a summary for vector types

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

show more ...

When I introduced hard-coded formatters, I made them non-cacheable

This is because - in theory - the formatter could match on not just the type, but also other properties of a ValueObject, so a per-

When I introduced hard-coded formatters, I made them non-cacheable

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

show more ...

Add a formatter for wchar_t[N] arrays

rdar://21299888

llvm-svn: 239777

Revert "Introduce a TypeSystem interface to support adding non-clang languages."

This seems to break expression evaluation on the linux build.

llvm-svn: 239366