================
@@ -2045,14 +2045,17 @@ TypeSP
SymbolFileNativePDB::CreateTypedef(PdbGlobalSymId id) {
if (!ts)
return nullptr;
- ts->GetNativePDBParser()->GetOrCreateTypedefDecl(id);
+ auto *typedef_decl = ts->GetNativePDBParser()->GetOrCreateTypedefDecl(id);
+
+ CompilerType ct = target_type->GetForwardCompilerType();
+ if (auto *clang = llvm::dyn_cast_or_null<TypeSystemClang>(ts.get()))
+ ct = clang->GetType(clang->getASTContext().getTypeDeclType(typedef_decl));
----------------
Nerixyz wrote:
> What use does `GetOrCreateType` have here? If that's not the thing that
> creates the correct `TypedefType`? Or in other words, could you elaborate on
> how this fixes the issue?
Ah, I left out the confusing/unintuitive part:
Currently, in the PDBs produced by both MSVC and LLVM, type aliases are _not_
in the "type system" (TPI stream/`LF_*` records;
https://redirect.github.com/llvm/llvm-project/pull/153936 attempts to change
this in LLVM).
`GetOrCreateType` looks in the PDB type stream TPI. The typedefs we currently
have are from `S_UDT` records in the globals stream, so they're represented as
"symbols" and `GetOrCreateType` would not be able to create the type.
Because of this, they're handled differently.
---
> Does that mean we create two different typedefs?
No, `clang::ASTContext::getTypeDeclType` will use
[`TypeForDecl`](https://github.com/llvm/llvm-project/blob/91f4db77b07368b47d32eb4d384fda2b2e5c9617/clang/include/clang/AST/Decl.h#L3517-L3521)
to get back to the type.
https://github.com/llvm/llvm-project/pull/156250
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
