<feed xmlns='http://www.w3.org/2005/Atom'>
<title>bcm5719-llvm/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime, branch meklort-10.0.1</title>
<subtitle>Project Ortega BCM5719 LLVM</subtitle>
<id>https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/'/>
<updated>2020-01-14T01:38:04+00:00</updated>
<entry>
<title>[LanguageRuntime] Retire an unused member function. NFCI.</title>
<updated>2020-01-14T01:38:04+00:00</updated>
<author>
<name>Davide Italiano</name>
<email>ditaliano@apple.com</email>
</author>
<published>2020-01-14T01:37:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=fb51ce10d7dcab9209d0cd059d907810dbd0197d'/>
<id>urn:sha1:fb51ce10d7dcab9209d0cd059d907810dbd0197d</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Remove extraneous spaces</title>
<updated>2020-01-07T15:46:04+00:00</updated>
<author>
<name>Med Ismail Bennani</name>
<email>medismail.bennani@gmail.com</email>
</author>
<published>2020-01-07T15:43:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=9daa44c9935053508b38d0203ac47130c8156b02'/>
<id>urn:sha1:9daa44c9935053508b38d0203ac47130c8156b02</id>
<content type='text'>
Signed-off-by: Med Ismail Bennani &lt;medismail.bennani@gmail.com&gt;
</content>
</entry>
<entry>
<title>[lldb][NFC] Take a llvm::Triple in ClangASTContext constructor</title>
<updated>2020-01-07T09:50:59+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2020-01-07T09:37:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=d364815351a887cbcd4579bc41995f8b2eb185ff'/>
<id>urn:sha1:d364815351a887cbcd4579bc41995f8b2eb185ff</id>
<content type='text'>
This constructor is supposed to take a string representing an llvm::Triple.
We might as well take a llvm::Triple here which saves us all the string
conversions in the call sites and we make this more type safe.
</content>
</entry>
<entry>
<title>[lldb][NFC] Create type-safe function for creating a CompilerType from a QualType</title>
<updated>2020-01-02T10:54:45+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-12-30T20:20:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=fe8e25a48a2a0f8f508499ba950181dba3d600b0'/>
<id>urn:sha1:fe8e25a48a2a0f8f508499ba950181dba3d600b0</id>
<content type='text'>
LLDB frequently converts QualType to CompilerType. This is currently done like this:
    result = CompilerType(this, qual_type_var.getAsOpaquePtr())
There are a few shortcomings in this current approach:
  1. CompilerType's constructor takes a void* pointer so it isn't type safe.
  2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type
     actually belongs to the passed ClangASTContext) without expanding the TypeSystem API.
  3. The logic for converting QualType-&gt;CompilerType is spread out over all of LLDB so
     changing it is difficult (e.g., what if we want to just pass the type ptr and not the
     1type_ptr | qual_flags1 to CompilerType).

This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl
functions that does this conversion in a type safe way.

It also adds a sanity check for Tag-based types that the type actually belongs to the
current ClangASTContext (Types don't seem to know their ASTContext, so we have to
workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types
we construct but it's better than no sanity check).
</content>
</entry>
<entry>
<title>[lldb][NFC] Remove GetASTContext call in ClangDeclVendor</title>
<updated>2019-12-28T14:20:19+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-12-28T13:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=8612e92ed590e615f9f56e4fb86a1fdaf3a39e15'/>
<id>urn:sha1:8612e92ed590e615f9f56e4fb86a1fdaf3a39e15</id>
<content type='text'>
Instead of returning NamedDecls and then calling GetASTContext
to find back the ClangASTContext we used can just implement the
FindDecl variant that returns CompilerDecls (and implement the
other function by throwing away the ClangASTContext part of the
compiler decl).
</content>
</entry>
<entry>
<title>[lldb][NFC] Use ClangASTContext in AppleObjCRuntime interfaces</title>
<updated>2019-12-26T15:23:40+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-12-26T13:52:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=37339d1426d1092aeb6ba3a4939b9efd6c1e2987'/>
<id>urn:sha1:37339d1426d1092aeb6ba3a4939b9efd6c1e2987</id>
<content type='text'>
This code actually needs a ClangASTContext but instead takes a
clang::ASTContext and then retrieves the original ClangASTContext
via the global map of ClangASTContexts. Let's change it so
that it takes a ClangASTContext which is simpler and faster.
</content>
</entry>
<entry>
<title>[lldb][NFC] Remove ClangExternalASTSourceCommon</title>
<updated>2019-12-24T12:17:27+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-12-23T19:42:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=4657a397c22a27775823b8f731abdc6477badfea'/>
<id>urn:sha1:4657a397c22a27775823b8f731abdc6477badfea</id>
<content type='text'>
ClangExternalASTSourceCommon's purpose is to store a map from
Decl*/Type* to ClangASTMetadata. Usually this data is accessed
via the ClangASTContext interface which then grabs the
current ExternalASTSource of its ASTContext, tries to cast it
to ClangExternalASTSourceCommon and then accesses the metadata
map. If the casting fails the setter does nothing and the getter
returns a nullptr as if there was no known metadata for a type/decl.

This system breaks as soon as any non-LLDB ExternalASTSource is added via
a multiplexer to our existing ExternalASTSource (in which case we suddenly
loose all out metadata as the casting always fails with an ExternalASTSource
that is not inheriting from ClangExternalASTSourceCommon).

This patch moves the metadata map to the ClangASTContext. This gets
rid of all the fragile casting, the requirement that every ExternalASTSource in
LLDB has to inherit from ClangExternalASTSourceCommon and simplifies
the metadata implementation to a simple map lookup. As ClangExternalASTSourceCommon
had no other purpose than storing metadata, this patch deletes this class
and replaces all uses with clang::ExternalASTSource.

No other code changes in this commit beside the AppleObjCDeclVendor which
was the only code that did not use the ClangASTContext interface but directly
accessed the ClangExternalASTSourceCommon.
</content>
</entry>
<entry>
<title>[lldb][NFC] Return a reference from ClangASTContext::getASTContext and remove dead nullptr checks</title>
<updated>2019-12-21T21:51:35+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-12-21T21:40:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=f9f49d3594bc7584cc5cb96125ca08f2ad97662c'/>
<id>urn:sha1:f9f49d3594bc7584cc5cb96125ca08f2ad97662c</id>
<content type='text'>
ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a
while that the ASTContext is not a nullptr. This causes that we still have a lot of code
that is doing nullptr checks on the result of getASTContext() which is all unreachable code.

This patch changes the return value to a reference to make it clear this can't be a nullptr
and deletes all the nullptr checks.
</content>
</entry>
<entry>
<title>[lldb][NFC] Use StringRef in CreateRecordType and CreateObjCClass</title>
<updated>2019-12-17T15:10:34+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-12-17T15:00:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=268f37df6e45c4b0603bd4d964483a0d84da44c1'/>
<id>urn:sha1:268f37df6e45c4b0603bd4d964483a0d84da44c1</id>
<content type='text'>
</content>
</entry>
<entry>
<title>[lldb] Remove modern-type-lookup</title>
<updated>2019-12-17T11:24:31+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-12-17T11:22:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=ff0102b32cfe506dfc16a86e38e70b0940697aa2'/>
<id>urn:sha1:ff0102b32cfe506dfc16a86e38e70b0940697aa2</id>
<content type='text'>
Summary:
As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup.

This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup
setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around
for now).

The motivation for this is that I don't think that the current approach of implementing modern-type-lookup
will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone
and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has
so far made the transition work much more complicated than it has to be.

A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization
in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly
the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring
and actually testing the existing code we have.

[1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html

Reviewers: shafik, martong

Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71562
</content>
</entry>
</feed>
