================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
