This is an archive of the discontinued LLVM Phabricator instance.

[clang] Improve LLVM-style RTTI support in ExternalASTSource/ExternalSemaSource
ClosedPublic

Authored by teemperor on Dec 12 2019, 12:36 AM.

Details

Summary

We currently have some very basic LLVM-style RTTI support in the ExternalASTSource class hierarchy
based on the SemaSource bool( to discriminate it form the ExternalSemaSource). As ExternalASTSource
is supposed to be subclassed we should have extendable LLVM-style RTTI in this class hierarchy to make life easier
for projects building on top of Clang.

Most notably the current RTTI implementation forces LLDB to implement RTTI for its
own ExternalASTSource class (ClangExternalASTSourceCommon) by keeping a global set of
ExternalASTSources that are known to be ClangExternalASTSourceCommon. Projects
using Clang currently have to dosimilar workarounds to get RTTI support for their subclasses.

This patch turns this into full-fledged LLVM-style RTTI based on a static ID variable similar to
other LLVM class hierarchies. Also removes the friend declaration from ExternalASTSource to
its child class that was only used to grant access to the SemaSource member.

Diff Detail

Event Timeline

teemperor created this revision.Dec 12 2019, 12:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 12 2019, 12:36 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I didn't add specific ID's to all of the subclasses in clang/clang-tools-extra because we never actually check for these specific classes anywhere from what I can see. But if anyone thinks that would be useful to have then I can update the patch.

aprantl accepted this revision.Dec 12 2019, 9:04 AM
aprantl added inline comments.
clang/include/clang/AST/ExternalASTSource.h
69–70

/// LLVM-style RTTI.

327
/// LLVM-style RTTI.
/// \{
...
/// \}
clang/include/clang/Sema/ExternalSemaSource.h
53

etc

This revision is now accepted and ready to land.Dec 12 2019, 9:04 AM

Side note: This https://reviews.llvm.org/D39111 seems related. The patch has languished as I have been busy with other work, but if it would be useful for you guys I'd be happy to try to land it.

rjmccall added inline comments.Dec 12 2019, 4:03 PM
clang/include/clang/AST/ExternalASTSource.h
69–70

It would be better if this had a dedicated type instead of using char and then void* as the parameter, just to prevent simple bugs where somebody passes in the wrong pointer. Maybe you could have a non-copyable ClassID type and a ClassRef type with the sole constructor ClassRef(const ClassID &)?

The virtual method name is trying too hard to be succinct, and it doesn't matter because it's rarely used; I would recommend borrowing the name isKindOf from Objective-C.

aprantl added a subscriber: labath.Dec 13 2019, 2:38 PM
aprantl added inline comments.
clang/include/clang/AST/ExternalASTSource.h
69–70

This is a pattern that is used all over in LLDB. However, these are good suggestions, and we might want to make those improvements there as well.

If this is commonly used, it would make sense to introduce those types into some common header in LLVM.

teemperor marked an inline comment as done.Dec 13 2019, 2:54 PM

Side note: This https://reviews.llvm.org/D39111 seems related. The patch has languished as I have been busy with other work, but if it would be useful for you guys I'd be happy to try to land it.

Moving ExternalASTSource to that system would also work, but that would add yet another dependency to D71398 (which is removing really gnarly code). But otherwise this seems like something we could use here (and also in LLDB).

I would prefer landing this as-is because it is just doing the same we do in other places in LLVM. Afterwards migrating the whole RTTI system in LLVM to a new system (whether that will be D39111 or just a ClassID type) sounds good to me.

If we decide as a community that D39111 is better, we can go back and adopt it at any point; I don't see that as a reason to reject modest refinements, especially given that there is no sign whatsoever of movement on D39111.

I would prefer landing this as-is because it is just doing the same we do in other places in LLVM. Afterwards migrating the whole RTTI system in LLVM to a new system (whether that will be D39111 or just a ClassID type) sounds good to me.

Yep -- To be clear I didn't raise D39111 as an objection to this approach, just as a matter of interest. As you noted it should be easy to switch later.

teemperor updated this revision to Diff 233968.Dec 15 2019, 8:18 AM
  • Addressed Adrian's comments.
This revision was automatically updated to reflect the committed changes.