Page MenuHomePhabricator

[Symbol] Decouple clang from CompilerType
ClosedPublic

Authored by xiaobai on Aug 12 2019, 11:53 AM.

Details

Summary

Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.

Diff Detail

Repository
rL LLVM

Event Timeline

xiaobai created this revision.Aug 12 2019, 11:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 12 2019, 11:53 AM
vsk added a subscriber: vsk.Aug 12 2019, 1:51 PM
davide accepted this revision.Aug 12 2019, 2:21 PM

LGTM

This revision is now accepted and ready to land.Aug 12 2019, 2:21 PM
JDevlieghere accepted this revision.Aug 12 2019, 4:01 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 13 2019, 12:41 PM

Should we add some sort of convenience function or a ClangCompilerType subclass of CompilerType that reduces the amount of boilerplate needed on the RHS?

... or a method ClangASTContext::wrapClangType()?

I wouldn't mind adding something to reduce boilerplate, but I'm not sure it would actually look too different. A wrapper function or subclass constructor would need to take a ClangASTContext and a clang::QualType so we could avoid calls to getAsOpaquePtr() everywhere but that's about it I think?

Let's pick some random examples:

CompilerType(ClangASTContext::GetASTContext(m_ast_source.m_ast_context), generic_function_type.getAsOpaquePtr())
->
ClangASTContext::GetASTContext(m_ast_source.m_ast_context).GetCompilerType(generic_function_type)

or

CompilerType(this, llvm::cast<clang::AutoType>(qual_type)->getDeducedType().getAsOpaquePtr())
->
GetCompilerType(llvm::cast<clang::AutoType>(qual_type)->getDeducedType())

Perhaps it really doesn't matter too much.