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