A recent change increased the stack size of memoizedMatchesAncestorOfRecursively
leading to stack overflows on real code involving large fold expressions.
It's not totally unreasonable to choke on very deep ASTs, but as common
infrastructure it's be nice if ASTMatchFinder is more robust.
(It already uses data recursion for the regular "downward" traversal.)
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/ASTMatchers/ASTMatchFinder.cpp | ||
---|---|---|
705 | this API makes sense, I'm wondering whether we should do it further (more aligned with matchesChildOf pattern):
I'm also ok with the current way. | |
738 | nit: I think we should explicitly describe (either in the comment or name) these keys are for the single-parent *chain*. It took me a while to understand what are these keys for? | |
740 | maybe Finish => Memorize | |
809 | nit: assert(Parents.size() > 1). |
bump this in case you have missed this patch :) our another internal pipeline seems to need this fix.
clang/lib/ASTMatchers/ASTMatchFinder.cpp | ||
---|---|---|
705 | I'm happy with that change, but I'd rather not bundle it into this one. | |
740 |
Memoize and Memorize are different words, and memoize doesn't act on results but rather on functions. So I think this rename is confusing.
Done |
this API makes sense, I'm wondering whether we should do it further (more aligned with matchesChildOf pattern):
I'm also ok with the current way.