This change exposes the various CodeGenTypes::ConvertType functions in the public Clang API. This allows external tools using the Clang API to rely on it to generate LLVM types from C types. The precise use case that motivated this change is explained in an email to the Clang mailing list.
Exposing these operations seems fine, but I'm not thrilled about the APIs. Of course, the APIs are exactly derived from IRGen's internal APIs, but we'd like to eventually clean those APIs up, and we certainly don't need to emulate them.
Is this one actually important to expose? What sorts of future APIs are you expecting where clients will interact with IRGen other than in memory?
If we do need this, we should name it something clear so that people don't accidentally reach for it by default. (This has actually been a pain point within IRGen for years.) How about:
llvm;:Type *convertTypeForRValue(CodeGenModule &CGM, QualType type);
Let's make this a specific API for getting the type of a function declaration.
llvm::FunctionType *convertFreeFunctionType(CodeGenModule &CGM, const FunctionDecl *FD);
llvm::Type *convertTypeForMemory(CodeGenModule &CGM, QualType type);
Patch updated based on @rjmccall's comments. I removed the wrapper for the ConvertType function, after giving it some thoughts I don't see any use case for it, I guess I added it by default. I left the convertFreeFunction function as returning an llvm::Type instead of an llvm::FunctionType as ConvertFunctionType represents incomplete function types as empty aggregate types.