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.

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.