Remove ConstString from Language, LanguageRuntime, SystemRuntime and SymbolFile plugin names

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

Differential Revision: https://reviews.llvm.org/D111877

show more ...

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://reviews.llvm.org/D109600

show more ...

Revert "[lldb] Refactor Module::LookupInfo constructor"

This reverts commit cd2134e42aa7d1168a3ed54e41793b022f961b1f.

Seems like this broke some tests on arm and aarch64 boxes. Will
investigate bef

Revert "[lldb] Refactor Module::LookupInfo constructor"

This reverts commit cd2134e42aa7d1168a3ed54e41793b022f961b1f.

Seems like this broke some tests on arm and aarch64 boxes. Will
investigate before re-landing.

show more ...

[lldb] Refactor Module::LookupInfo constructor

Module::LookupInfo's constructor currently goes over supported languages
trying to figure out the best way to search for a symbol name. This
seems like

[lldb] Refactor Module::LookupInfo constructor

Module::LookupInfo's constructor currently goes over supported languages
trying to figure out the best way to search for a symbol name. This
seems like a great candidate for refactoring. Specifically, this is work
that can be delegated to language plugins.

Once again, the goal here is to further decouple plugins from
non-plugins. The idea is to have each language plugin take a name and
give you back some information about the name from the perspective of
the language. Specifically, each language now implements a
`GetFunctionNameInfo` method which returns an object of type
`Language::FunctionNameInfo`. Right now, it consists of a basename,
a context, and a FunctionNameType. Module::LookupInfo's constructor will
call `GetFunctionNameInfo` with the appropriate language plugin(s) and
then decide what to do with that information. I have attempted to maintain
existing behavior as best as possible.

A nice side effect of this change is that lldbCore no longer links
against the ObjC Language plugin.

Differential Revision: https://reviews.llvm.org/D108229

show more ...

Re-land "[lldb] Upstream support for Foundation constant classes"

Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.

We would've

Re-land "[lldb] Upstream support for Foundation constant classes"

Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.

We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.

I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.

Differential revision: https://reviews.llvm.org/D107660

show more ...

Revert "[lldb] Upstream support for Foundation constant classes"

This reverts commit 34d78b6a6755946e547afc47d38b59b6a2854457.

This breaks build bots witha missing file:
/home/worker/2.0.1/lldb-x8

Revert "[lldb] Upstream support for Foundation constant classes"

This reverts commit 34d78b6a6755946e547afc47d38b59b6a2854457.

This breaks build bots witha missing file:
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:10:10: fatal error: 'objc/runtime.h' file not found

show more ...

[lldb] Upstream support for Foundation constant classes

Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.

We would've upstreame

[lldb] Upstream support for Foundation constant classes

Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.

We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.

I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.

Differential revision: https://reviews.llvm.org/D107660

show more ...

[lldb] Rename StringRef _lower() method calls to _insensitive()

[lldb] Decouple ObjCLanguage from Symtab

We can extend/modify `GetMethodNameVariants` to suit our purposes here.
What symtab is looking for is alternate names we may want to use to
search for a spec

[lldb] Decouple ObjCLanguage from Symtab

We can extend/modify `GetMethodNameVariants` to suit our purposes here.
What symtab is looking for is alternate names we may want to use to
search for a specific symbol, and asking for variants of a name makes
the most sense here.

Differential Revision: https://reviews.llvm.org/D104067

show more ...

[lldb][NFC] Use Language plugins in Mangled::GuessLanguage

This removes the direct dependency to the ObjC and C++ plugins.

Reviewed By: bulbazord

Differential Revision: https://reviews.llvm.org/D1

[lldb][NFC] Use Language plugins in Mangled::GuessLanguage

This removes the direct dependency to the ObjC and C++ plugins.

Reviewed By: bulbazord

Differential Revision: https://reviews.llvm.org/D103158

show more ...

[lldb] Move ClangModulesDeclVendor ownership to ClangPersistentVariables from Target

More decoupling of plugins and non-plugins. Target doesn't need to
manage ClangModulesDeclVendor and ClangPersist

[lldb] Move ClangModulesDeclVendor ownership to ClangPersistentVariables from Target

More decoupling of plugins and non-plugins. Target doesn't need to
manage ClangModulesDeclVendor and ClangPersistentVariables is always available
in situations where you need ClangModulesDeclVendor.

Differential Revision: https://reviews.llvm.org/D102811

show more ...

[lldb/Dataformatter] Add support to CF{Dictionary,Set}Ref types

This patch improves data formatting for CFDictionaryRef and CFSetRef.
It uses the same data-formatter as NSCFDictionaries and NSCFSets

[lldb/Dataformatter] Add support to CF{Dictionary,Set}Ref types

This patch improves data formatting for CFDictionaryRef and CFSetRef.
It uses the same data-formatter as NSCFDictionaries and NSCFSets introduced
previously but did require some adjustments in Core::ValueObject.

Since the "Ref" types are opaque pointers to the actual CF containers, if the
value object has a synthetic value, lldb will use the opaque pointer's pointee
type to create the new ValueObjectChild needed to dereference the ValueObject.
This allows the "Ref" types to behaves the same as CF containers when used with
the `frame variable` command, the SBAPI or in Xcode's variable inspector.

This patch also adds support for incomplete types in ValueObject.

rdar://53104287

Differential Revision: https://reviews.llvm.org/D79554

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

[lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets.

This patch improves data formatting for CoreFoundation containers:
CFDictionary and CFSet.

These data formatters make the

[lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets.

This patch improves data formatting for CoreFoundation containers:
CFDictionary and CFSet.

These data formatters make the containers and their children appear in Xcode's
variables view (and on the command line) without having to expand the
data structure.

Previous implementation only supported showing the container's element count.

```
(lldb) frame var dict
(__NSCFDictionary *) dict = 0x00000001004062b0 2 key/value pairs

(lldb) frame var set
(__NSCFSet *) set = 0x0000000100406330 2 elements
```
Now the variable can be dereferenced to dispaly the container's children:

```
(lldb) frame var *dict
(__NSCFDictionary) *dict = {
[0] = {
key = 0x0000000100004050 @"123"
value = 0x0000000100004090 @"456"
}
[1] = {
key = 0x0000000100004030 @"abc"
value = 0x0000000100004070 @"def"
}
}

(lldb) frame var *set
(__NSCFSet) *set = {
[0] = 0x0000000100004050 @"123"
[1] = 0x0000000100004030 @"abc"
}
```

rdar://39882287

Differential Revision: https://reviews.llvm.org/D78396

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

[lldb/Plugin] s/LLDB_PLUGIN/LLDB_PLUGIN_DEFINE/ (NFC)

Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to
avoid name conflict.

[LLDB] Fix GCC warnings about extra semicolons. NFC.

[lldb/Plugins] Use external functions to (de)initialize plugins

This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to

[lldb/Plugins] Use external functions to (de)initialize plugins

This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to
disable plugins at configuration time.

Differential revision: https://reviews.llvm.org/D74245

show more ...

[lldb] Move clang-based files out of Symbol

Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSyst

[lldb] Move clang-based files out of Symbol

Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h

This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.

Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik

Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73661

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258

show more ...

[lldb][NFC] Rename ClangASTContext to TypeSystemClang

Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the Type

[lldb][NFC] Rename ClangASTContext to TypeSystemClang

Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).

I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.

Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai

Reviewed By: clayborg, labath, xiaobai

Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72684

show more ...

[lldb] Add missing include to ObjCLanguage.cpp to fix build

[lldb] Check if we actually have a Clang type in ObjCLanguage::GetPossibleFormattersMatches

We call IsPossibleDynamicType but we also need to check if this is a Clang type,
otherwise other languages

[lldb] Check if we actually have a Clang type in ObjCLanguage::GetPossibleFormattersMatches

We call IsPossibleDynamicType but we also need to check if this is a Clang type,
otherwise other languages with dynamic types (like Swift) might end up being interpreted
as potential Obj-C dynamic types.

show more ...

[Symbol] Give ClangASTContext a PersistentExpressionState instead of a ClangPersistentVariables

ClangASTContext doesn't use m_persistent_variables in a way specific to
ClangPersistentVariables. Ther

[Symbol] Give ClangASTContext a PersistentExpressionState instead of a ClangPersistentVariables

ClangASTContext doesn't use m_persistent_variables in a way specific to
ClangPersistentVariables. Therefore, it should hold a unique pointer to
PersistentExpressionState instead of a ClangPersistentVariablesUP.
This also prevents you from pulling in a plugin header when including
ClangASTContext.h

Doing this exposed an implicit dependency in ObjCLanguage that was
corrected by including ClangModulesDeclVendor.h

llvm-svn: 371470

show more ...

[LanguageRuntime] Move ObjCLanguageRuntime into a plugin

Summary:
Following up to my CPPLanguageRuntime change, I'm moving
ObjCLanguageRuntime into a plugin as well.

Reviewers: JDevlieghere, compne

[LanguageRuntime] Move ObjCLanguageRuntime into a plugin

Summary:
Following up to my CPPLanguageRuntime change, I'm moving
ObjCLanguageRuntime into a plugin as well.

Reviewers: JDevlieghere, compnerd, jingham, clayborg

Subscribers: mgorny, arphaman, lldb-commits

Differential Revision: https://reviews.llvm.org/D64763

llvm-svn: 366148

show more ...

[Symbol] Add DeclVendor::FindTypes

Summary:
Following up on the plan I outlined in D63622, we can remove the
dependence on clang in all the places where we only want to find the
types from the DeclV

[Symbol] Add DeclVendor::FindTypes

Summary:
Following up on the plan I outlined in D63622, we can remove the
dependence on clang in all the places where we only want to find the
types from the DeclVendor. This means that currently DeclVendor depends
on clang, but centralizing the dependency makes it easier to refactor
cleanly.

Differential Revision: https://reviews.llvm.org/D63853

llvm-svn: 364962

show more ...