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