aaron.ballman added a comment. In D80603#2059122 <https://reviews.llvm.org/D80603#2059122>, @gribozavr2 wrote:
> In D80603#2058019 <https://reviews.llvm.org/D80603#2058019>, @aaron.ballman > wrote: > > > I'm sorry if I'm being dense, but `hasParameter` traverses to the > > `ParmVarDecl`, so I'm not certain I understand why this new matcher is > > needed as a public matcher. It seems like you can already accomplish this > > without adding a second API to do effectively the same thing: > > `functionDecl(hasParameter(0, parmVarDecl().bind("param")))`, can't you? > > > It is syntax sugar, true. Note that the proposed matcher is a narrowing > matcher for `parmVarDecl()`, while your suggestion is a narrowing matcher for > `functionDecl()`, so it is not an entirely apples-to-apples comparison. Think > about use cases like: `declRefExpr(to(parmVarDecl(at(...))))`. To rewrite > that with `hasParameter()`, we have to use `hasAncestor` to find the > `functionDecl` first, and then compare the AST node pointers. So while it is > possible to express this proposed operation today, it requires a complex > matcher for such a conceptually simple operation. Thank you, that clarifies the need nicely for me! Is there a reason we want to support blocks but not lambdas? Also, you need to update Registry.cpp to add this to the list of dynamic matchers. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80603/new/ https://reviews.llvm.org/D80603 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
