[PATCH] D122121: [clang][dataflow] Add action caching support to MatchSwitch

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

What is the motivation for stashing the results of a match on a statement? Do we expect to encounter the same statement often?

I thought the concern was more specific to re-matching particular types, like `std::optional`. For that, we could lazily store the declaration nodes (like we do in https://github.com/llvm/llvm-project/blob/main/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp with `CheckDecls`).  But, I'm less clear on the impact of storing the result of the match itself.

For the decls concern, I think we'll want evidence of the cost before we try to optimize it. The `hasName` matcher is already optimized, so I'm not sure how much we have to gain here. Something, but probably not a lot.



================
Comment at: clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h:159
+  static std::function<void(State &)>
+  BuildMatcherForStmt(const ast_matchers::internal::DynTypedMatcher &Matcher,
+                      const std::vector<Action> &Actions, const Stmt &Stmt,
----------------
What is this function doing?  Please add a comment. Also, I don't understand how it compiles -- the return type is `std::function<void(State &)>` but it returns a lambda of type `(State &S) -> std::function<void(State &)>`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122121/new/

https://reviews.llvm.org/D122121