Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5
Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
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
.. and reduce the scope of others. They don't follow llvm coding
standards (which say they should be used only when the same effect
cannot be achieved with the static keyword), and they set a bad example.
This change accomplishes the following:
- Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`.
- Renames `FindBestAlternateMangledName` to
`FindBestAlternateFunctionMangledName`
- Changes the first parameter of said method from a `ConstString`
representing a demangled name to a `Mangled`.
- Remove the use of CPlusPlusLanguage from Expression
I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
IRExecutionUnit::FindBestAlternateMangledName. These are named very
similar things, they try to do very similar things, but their
approaches are different. This change should make it clear that one
is generating possible alternate manglings (through some
heuristics-based approach) and the other is finding alternate
manglings (through searching the SymbolFile for potential matches).
2. Change GenerateAlternateFunctionManglings from a static method in
CPlusPlusLanguage to a virtual method in Language. This will allow us
to remove a direct use of CPlusPlusLanguage in IRExecutionUnit,
further pushing it to be more general. This change doesn't meet this
goal completely but allows for it to happen later.
Though this doesn't remove IRExecutionUnit's dependency on
CPlusPlusLanguage, it does bring us closer to that goal.
Differential Revision: https://reviews.llvm.org/D109785
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
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
Move Objective-C constants into ObjCConstants.h and share them between
Cocoa and AppleObjCTypeEncodingParser.
Differential revision: https://reviews.llvm.org/D107679
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
This reverts commit 34d78b6a67.
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
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
lldb_private::DataExtractor contains DataBufferSP m_data_sp which is
relatively expensive to copy (due to multi-threading locking).
llvm::DataExtractor does not have this problem as it uses StringRef
instead.
The copy constructor is explicit as otherwise it is easy to make
unintended modification of a local copy instead of a caller's instance
(D107470 but that is llvm::DataExtractor).
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D107485
The only remaining plugin dependency in Mangled is CPlusPlusLanguage which it
uses to extract information from C++ mangled names. The static function
GetDemangledNameWithoutArguments is written specifically for C++, so it
would make sense for this specific functionality to live in a
C++-related plugin. In order to keep this functionality in Mangled
without maintaining this dependency, I added
`Language::GetDemangledFunctionNameWithoutArguments`.
Differential Revision: https://reviews.llvm.org/D105215
This was an oversight of the commit: bb93483c11 that
added support for the Frozen variants. Also added a test case for the way that
currently produces one of these variants (a copy).
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
libstdc++ since version 11 has a conditional compilation based on
[[no_unique_address]] availability whether one element is either
inherited or put there as a field with [[no_unique_address]].
The code comment is by teemperor.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104283
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix
This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.
Differential revision: https://reviews.llvm.org/D103483
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
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
These types also wanted to be/were copy assignable, and using the
implicit copy ctor is deprecated in the presence of an explicit copy
ctor.
Removing the explicit copy ctor provides the desired behavior - both
ctor and assignment operator are available implicitly.
Also while I was nearby there were some missing std::moves on shared
pointer parameters.
Right now to get the 'NSSet *` pointer value we first derefence it and then take
the address of the result.
Beside being inefficient this potentially can cause an infinite recursion if the
`pointer` value we get is a pointer of a type that the TypeSystem can't
derefence. If the pointer is for example some form of `void *` that the dynamic
type resolution can't resolve to an actual type, then the `Derefence` call goes
back to asking the formatters how to reference it. If the NSSet formatter then
checks if it's an NSSet variation under the hood then we just end infinitely
often recursion.
In practice this seems to happen with some form of Builtin.RawPointer we get
from a NSDictionary in Swift.
FWIW, no other formatter is doing the same deref->addressOf as here and there
doesn't seem to be any specific reason to do so in the git history (it's just
part of the initial formatter commit)
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D101537
This reverts commit 602ab188a7.
The patch replicated an lldbassert for a certain type of NSNumber for tagged
pointers. This really shouldn't be an assert since we don't do anything wrong
with these numbers, we just don't print a summary. So this patch changed the
lldbassert to a log message in reverting the revert.
This reverts commit 4d9039c8dc.
This is causing the greendragon bots to fail most of the time when
running TestNSDictionarySynthetic.py. Reverting until Jim has a chance
to look at this on Monday. Running the commands from that test from
the command line, it fails 10-13% of the time on my desktop.
This is a revert of Jim's changes in https://reviews.llvm.org/D99694
The ObjC runtime offers both signed & unsigned tagged pointer value
accessors to tagged pointer providers, but lldb's tagged pointer
code only implemented the unsigned one. This patch adds an
emulation of the signed one.
The motivation for doing this is that NSNumbers use the signed
accessor (they are always signed) and we need to follow that in our
summary provider or we will get incorrect values for negative
NSNumbers.
The data-formatter-objc test file had NSNumber examples (along with lots of other
goodies) but the NSNumber values weren't tested. So I also added
checks for those values to the test.
I also did a quick audit of the other types in that main.m file, and
it looks like pretty much all the other values are either intermediates
or are tested.
Differential Revision: https://reviews.llvm.org/D99694
Add frame variable dereference suppport to libc++ `std::unique_ptr`.
This change allows for commands like `v *thing_up` and `v thing_up->m_id`. These commands now work the same way they would with raw pointers, and as they would with expression. This is done by adding an unaccounted for child member named `$$dereference$$`.
Without this change, the command would have to be written as `v *thing_up.__value_` or v thing_up.__value_->m_id` which exposes internal structure and is more clumsy to type.
Additionally, the existing tests were updated. See also https://reviews.llvm.org/D97165 which added deref support for `std::shared_ptr`.
Differential Revision: https://reviews.llvm.org/D97524
Add `frame variable` dereference suppport to libc++ `std::shared_ptr`.
This change allows for commands like `v *thing_sp` and `v thing_sp->m_id`. These
commands now work the same way they do with raw pointers. This is done by adding an
unaccounted for child member named `$$dereference$$`.
Also, add API tests for `std::shared_ptr`, previously there were none.
Differential Revision: https://reviews.llvm.org/D97165
BlockPointerSyntheticFrontEnd does a CopyType which results in it copying the type
back into its own context. This will result in a call to ASTImporterDelegate::setOrigin
with &decl->getASTContext() == origin.ctx this can result in an infinite recursion
later on in ASTImporter since it will attempt to find the decl in its origin which will be itself.
Differential Revision: https://reviews.llvm.org/D96366
ObjCBOOLSummaryProvider was incorrectly treating BOOL as unsigned and this is now fixed.
Also adding tests for one bit bit-fields of BOOL and unsigned char.
Several data formatters assume their types are in the Target's scratch AST and
build new types from that scratch AST instance. However, types from different
ASTs shouldn't be mixed, so this (unchecked) assumption may lead to problems if
we ever have more than one scratch AST or someone somehow invokes data
formatters on a type that are not in the scratch AST.
Instead we can use in all the formatters just the TypeSystem of the type we're
formatting. That's much simpler and avoids all the headache of finding the right
TypeSystem that matches the one of the formatted type.
Right now LLDB only has one scratch TypeSystemClang instance and we format only
types that are in the scratch AST, so this doesn't change anything in the
current way LLDB works. The intention here is to allow follow up refactorings
that introduce multiple scratch ASTs with the same Target.
Differential Revision: https://reviews.llvm.org/D92757
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.
Differential revision: https://reviews.llvm.org/D77153
This reverts commit 856fd98a17. The type formatters
use inline namespaces to find the formatter that fits the type ABI, so they
can't just ignore the inline namespaces.
The failing tests should be fixed by da121fff11 .
On macOS Big Sur the class descriptor contains the NSKVONotifying_
prefix. This is covered by TestDataFormatterObjCKVO.
Differential revision: https://reviews.llvm.org/D87545
We saw a crash recently (rdar://problem/65276489) that looks related to an invalid ValueObjectSP in a summary providers in Cocoa.cpp e.g. NSBundleSummaryProvider(...).
This adds checks before we use them usually by calling NSStringSummaryProvider.
Differential Revision: https://reviews.llvm.org/D84272
Summary:
Certain `NSDate` constructors return a special `NSConstantDate` class which
currently ends up being unformatted as it's not in the list of supported classes
for the NSDate formatter. This patch adds that class to the supported class list
so LLDB produces a summary for it.
One of these special constructors is `[NSDate distantPast]` which returns the
date for `0001-01-01 00:00:00 UTC`. LLDB has a special case for formatting this
date but for some reason we did hardcode the wrong summary string in that
special case. Maybe the summary string was correct back when the code was
written but it isn't correct anymore (`distantPast` isn't actually defined to be
a special date but just some 'a guaranteed temporal boundary.' so maybe someone
changed the value in the last 10 years).
If someone else is wondering why we even have this special case for
`distantPast` but not for the future. The reason seems to be that our date
formatting for really old dates is off by 24 hours. So for example, adding one
second to `distantPast` will cause LLDB to print `0000-12-30 00:00:01 UTC`
(which is 24 hours behind the expected result). So to make our code appear to be
correct it seems we just hardcoded the most common NSDate result from that time
span. I'll replace that logic with a generic solution in a probably more
invasive follow up patch.
I also took the freedom to replace the magic value `-63114076800` with some
constant + documentation. I heard there are some people that don't know from the
top of their head that there are 63114076800 seconds between 1. Jan 0001 and 1.
January 2001 in whatever calendar system NSDate is using.
Reviewers: mib, davide
Reviewed By: mib
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83217
Summary:
When printing an NSDate (for example with `NSLog` or `po`) the seconds value is
always rounded down. LLDB's own formatter however isn't following that behaviour
which leads to situations where the formatted result is sometimes one second
off. For example:
```
(lldb) p [NSDate dateWithTimeIntervalSince1970:0.1]
(__NSTaggedDate *) $1 = [...] 1970-01-01 00:00:01 UTC
(lldb) po [NSDate dateWithTimeIntervalSince1970:0.1]
1970-01-01 00:00:00 +0000
(lldb) p [NSDate dateWithTimeIntervalSince1970:0.6]
(__NSTaggedDate *) $4 =[...] 1970-01-01 00:00:01 UTC
(lldb) po [NSDate dateWithTimeIntervalSince1970:0.6]
1970-01-01 00:00:00 +0000
```
This patch just always rounds down the seconds value we get from the NSDate
object.
Fixes rdar://65084800
Reviewers: mib, davide
Reviewed By: mib
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83221
The formatter was requesting an unsigned integer from the ValueObject,
but CFAbsoluteTime is a signed double, so in the NSDate test the formatter
actually just printed the 'error value' date which is the Cocoa epoch. This
started failing after the recent Scalar changes.
This patch just changes the logic to use a signed value which fits to the data
we try to read and avoids this issue.
Summary:
Since commit 7b3ef05a37 the Objective-C++ plugin is dead code.
That commit added Objective-C++ to the list of languages for which `Language::LanguageIsCPlusPlus`
returns true. As the C++ language plugin also uses that method to figure out if it is responsible for a
given language, the C++ plugin since then also became the plugin that we found when looking for
a language plugin for Objective-C++. The only real fallout from that is that the source highlighting
for Objective-C++ files never worked as we always found the C++ plugin which refuses to highlight
files with Objective-C++ extensions.
This patch just adds a special exception for Objective-C++ to the list of languages that are governed
by the C++ plugin. Also adds a test that makes sure that we find the right plugin for all C language
types and that the highlighting for `.mm` (Objective-C++) and `.m` (Objective-C) files works.
I didn't revert 7b3ef05a37 as it does make sense to return
true for Objective-C++ from `Language::LanguageIsCPlusPlus` (e.g., we currently check if we care about
ODR violations by doing `if (Language::LanguageIsCPlusPlus(...))` and this should also work for
Objective-C++).
Fixes rdar://64420183
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D82109
This reverts commit b783f70a42. This
change had multiple issues which required post-commit fixups, and not
all issues are fixed yet. In particular, the LLDB build bot for ARM is
still broken. There is also an ongoing conversation in the original
phabricator review about whether there is undefined behavior in the
code.
This addresses some post-commit review feedback from
https://reviews.llvm.org/D80150 by renaming "Mock.h" to something less
misleading, and keeping logic related to the ObjC plugin separate from
the generic DataFormatters library.
Summary:
Fixes UBSan-reported issues where the date value inside of an
uninitialized NSDate overflows the 64-bit epoch.
rdar://61774575
Reviewers: JDevlieghere, mib, teemperor
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80150
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 <medismail.bennani@gmail.com>
Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", but when
debugging Swift code the same string would look like "\u{8}".
To make this work, plugins override GetStringPrinterEscapingHelper.
However, because there's a large amount of subtly divergent work done in
each override, we end up with large amounts of duplicated code. And all
the memory smashers fixed in one copy of the logic (see D73860) don't
get fixed in the others.
IMO the GetStringPrinterEscapingHelper is overly general and hard to
use. I propose deleting it and replacing it with an EscapeStyle enum,
which can be set as needed by each plugin.
A fix for some swift-lldb memory smashers falls out fairly naturally
from this deletion (https://github.com/apple/llvm-project/pull/1046). As
the swift logic becomes really tiny, I propose moving it upstream as
part of this change. I've added unit tests to cover it.
rdar://61419673
Reviewers: JDevlieghere, davide
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77843
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 <medismail.bennani@gmail.com>
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments.
Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases.
It uses clang::Lexer which will tokenize operator<<A::B> into:
tok::kw_operator
tok::lessless
tok::raw_identifier
Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse.
Differential Revision: https://reviews.llvm.org/D76168
This adds a formatter for libc++ std::unique_ptr.
I also refactored GetValueOfCompressedPair(...) out of LibCxxList.cpp since I need the same functionality and it made sense to share it.
Differential Revision: https://reviews.llvm.org/D76476
(This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix
the Debian tests).
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).
It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.
This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).
Reviewers: aprantl, JDevlieghere, shafik
Reviewed By: aprantl
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68010
This reverts commit 939ca455e7.
This failed on the debian bot for some reason:
File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py", line 67, in test_with_run_command
"s summary wrong")
AssertionError: 'L"hello world! מזל טוב!\\0!\\0!!!!\\0\\0A\\0\\U0000fffd\\U0000fffd\\U0000fffd\\ [truncated]... != 'L"hello world! מזל טוב!"'
Diff is 2156 characters long. Set self.maxDiff to None to see it. : s summary wrong
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).
It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.
This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).
Reviewers: aprantl, JDevlieghere, shafik
Reviewed By: aprantl
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68010
Most clients of SourceManager.h need to do things like turning source
locations into file & line number pairs, but this doesn't require
bringing in FileManager.h and LLVM's FS headers.
The main code change here is to sink SM::createFileID into the cpp file.
I reason that this is not performance critical because it doesn't happen
on the diagnostic path, it happens along the paths of macro expansion
(could be hot) and new includes (less hot).
Saves some includes:
309 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileManager.h
272 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileSystemOptions.h
271 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/VirtualFileSystem.h
267 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/FileSystem.h
266 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Chrono.h
Differential Revision: https://reviews.llvm.org/D75406
Summary:
Currently when printing data types we include implicit scopes such as inline namespaces or anonymous namespaces.
This leads to command output like this (for `std::set<X>` with X being in an anonymous namespace):
```
(lldb) print my_set
(std::__1::set<(anonymous namespace)::X, std::__1::less<(anonymous namespace)::X>, std::__1::allocator<(anonymous namespace)::X> >) $0 = size=0 {}
```
This patch removes all the implicit scopes when printing type names in TypeSystemClang::GetDisplayTypeName
so that our output now looks like this:
```
(lldb) print my_set
(std::set<X, std::less<X>, std::allocator<X> >) $0 = size=0 {}
```
As previously GetDisplayTypeName and GetTypeName had the same output we actually often used the
two as if they are the same method (they were in fact using the same implementation), so this patch also
fixes the places where we actually want the display type name and not the actual type name.
Note that this doesn't touch the `GetTypeName` class that for example the data formatters use, so this patch
is only changes the way we display types to the user. The full type name can also still be found when passing
'-R' to see the raw output of a variable in case someone is somehow interested in that.
Partly fixes rdar://problem/59292534
Reviewers: shafik, jingham
Reviewed By: shafik
Subscribers: christof, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74478
Summary:
Currently the data formatter is treating `std::atomic` variables as transparent wrappers
around their underlying value type. This causes that when printing `std::atomic<A *>`, the data
formatter will forward all requests for the children of the atomic variable to the `A *` pointer type
which will then return the respective members of `A`. If `A` in turn has a member that contains
the original atomic variable, this causes LLDB to infinitely recurse when printing an object with
such a `std::atomic` pointer member.
We could implement a workaround similar to whatever we do for pointer values but this patch
just implements the `std::atomic` formatter in the same way as we already implement other
formatters (e.g. smart pointers or `std::optional`) that just model the contents of the as a child
"Value". This way LLDB knows when it actually prints a pointer and can just use its normal
workaround if "Value" is a recursive pointer.
Fixes rdar://59189235
Reviewers: JDevlieghere, jingham, shafik
Reviewed By: shafik
Subscribers: shafik, christof, jfb, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74310
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
The previously landed patch got reverted because it was lacking:
(1) A plugin definition for the Objective-C language runtime,
(2) The dependency between the Static and WASM dynamic loader,
(3) Explicit initialization of ScriptInterpreterNone for lldb-test.
All issues have been addressed in this patch.
Differential revision: https://reviews.llvm.org/D73067
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
Differential revision: https://reviews.llvm.org/D73067
m_size can only be 1 or 0 and indicates if the optional has a value. Calling
it 'm_size', giving it a size_t data type and then also comparing indices against
'size' is very confusing. Let's just make this a bool.
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
Summary:
lldb-forward.h is convenient in many ways, but having clang-based
class forward declarations in there makes it easy to proliferate uses of clang
outside of plugins. Removing them makes you much more conscious of when
you're using something from clang and marks where we're using things
from clang in non-plugins.
Differential Revision: https://reviews.llvm.org/D73935
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
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Target is one of the classes responsible for vending ClangASTImporter.
Target doesn't need to know anything about ClangASTImporter, so if we
instead have ClangPersistentVariables vend it, we can preserve
existing behavior while improving layering and removing dependencies
from non-plugins to plugins.
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
David Blaikie