[clang] [clang][ExtractAPI] combine typedef records if the underlying type's name is underscored (PR #125964)

[via cfe-commits]

================
@@ -1146,11 +1146,29 @@ bool ExtractAPIVisitorBase<Derived>::VisitTypedefNameDecl(
 
   StringRef Name = Decl->getName();
 
+  auto nameMatches = [&Name](TagDecl *TagDecl) {
+    StringRef TagName = TagDecl->getName();
+
+    if (TagName == Name)
+      return true;
+
+    // Also check whether the tag decl's name is the same as the typedef name
+    // with prefixed underscores
+    if (TagName.starts_with('_')) {
----------------
QuietMisdreavus wrote:

This is already limiting itself to underlying types which (1) are "tag decls", i.e. structs/classes/enums/unions, and (2) whose definitions are "embedded in a declarator", which AFAIK means that it's not going to catch typedefs of typedefs to begin with.

Now, I recently implemented [logic in the Swift compiler](https://github.com/swiftlang/swift/pull/78959) to catch the same situation i mentioned in the PR description, but in that PR i took a more general approach and folded together "public type aliases of types that are being hidden (e.g. underscored)". However, the Swift symbol graph generator didn't have its own notion of "folding decls together" yet, since in the average case the Swift Clang Importer already handles that, whereas here in Clang we were already handling `typedef struct` unification. (I also didn't go recursive in the Swift PR, but the nondeterministic ordering of AST walking could make that even more complicated! 😵‍💫)

I'm inclined to hold off on going recursive for now, and come back later if we need to handle `typedef _HiddenTypedef PublicTypedef` in this kind of way. I could see this becoming even more complicated in this kind of situation, to avoid revealing too many implementation details in an ostensibly public symbol graph rendering.

https://github.com/llvm/llvm-project/pull/125964