[llvm-branch-commits] [clang] [serialization] No transitive type change (PR #92511)
Chuanqi Xu via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Wed Jun 19 19:54:02 PDT 2024
================
@@ -7392,27 +7388,28 @@ QualType ASTReader::GetType(TypeID ID) {
return TypesLoaded[Index].withFastQualifiers(FastQuals);
}
-QualType ASTReader::getLocalType(ModuleFile &F, unsigned LocalID) {
+QualType ASTReader::getLocalType(ModuleFile &F, TypeID LocalID) {
----------------
ChuanqiXu9 wrote:
> Could we clarify what LocalID means here in a comment somewhere?
In ASTReader.h, there is a single line comment: `Resolve a local type ID within a given AST file into a type.`. I add a new line to explain it as "A local type ID is only meaningful with the corresponding module file. See the implementation of getGlobalTypeID for details.".
> IIUC, the ModuleFileIndex there is an index into F.TransitiveImports rather than into a "global" module manager.
Yes, this is correct for local ID. But I feel it might be odd to put this in the comment. I feel, it might be good to know, we can use `ASTReader::getGlobalTypeID` to convert a `<ModuleFile, LocalTypeID>` pair to a `GlobalTypeID`. And the concrete process is the implementation details to GlobalTypeID`.
> Previously, we had distinction between unsigned in parameters to this function and TypeID as a return type.
Maybe we should keep this here and accept uint64_t to avoid confusing the common global module file index and a local file index?
I don't feel it better. `uint64_t` doesn't provide any type information. To be best, maybe we can do something like for `LocalDeclID` and `GlobalDeclID`. I only did that for DeclID since I feel the DeclID is the most complicated and the TypeID are much more simpler. I think we can this later if we feel it is necessary.
https://github.com/llvm/llvm-project/pull/92511
More information about the llvm-branch-commits
mailing list