[clang-tools-extra] [clangd] Don't show inlay hints for __builtin_dump_struct (PR #71366)

[Younan Zhang via cfe-commits]

================
@@ -589,6 +589,24 @@ class InlayHintVisitor : public RecursiveASTVisitor<InlayHintVisitor> {
     return true;
   }
 
+  bool TraversePseudoObjectExpr(PseudoObjectExpr *E) {
+    // Do not show inlay hints for the __builtin_dump_struct, which would
+    // expand to a PseudoObjectExpr that includes a couple of calls to a
+    // printf function. Printing parameter names for that anyway would end up
+    // with duplicate parameter names (which, however, got de-duplicated after
+    // visiting) for the printf function.
+    if (auto *CE = dyn_cast<CallExpr>(E->getSyntacticForm());
+        CE && CE->getBuiltinCallee() == Builtin::BI__builtin_dump_struct)
+      // Only traverse the syntactic forms. This leaves the door open in case
+      // the arguments in the syntactic form for __builtin_dump_struct could
+      // possibly get parameter names.
+      return RecursiveASTVisitor<InlayHintVisitor>::TraverseStmt(
+          E->getSyntacticForm());
+    // FIXME: Shall we ignore semantic forms for other pseudo object
----------------
zyn0217 wrote:

I think this depends on our attitude towards parameter hints for other pseudo-expression usages. Take the getter case from the test for example, the expression for `S().x[1][2]` turns out to be
```
`-PseudoObjectExpr 'int'
 |- (Syntatic) MSPropertySubscriptExpr '<pseudo-object type>' lvalue
 `- (Semantic) CXXMemberCallExpr 'int'
```
There's no chance to see hints for the arguments if we neglect all the syntactic forms being `CallExpr`s. Besides, there are still some similar usages in ObjC / OpenMP that I'm not familiar with. 
Anyway, if we agree to sacrifice the chances to see these hints, I'd love to move forward with all `CallExpr`s within a pseudo-expression being dropped. Otherwise, I think it's better to leave it to the next bug report / feature request. What do you think?

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