Because we don't know in ASTMatchFinder whether we're matching in AsIs
or IgnoreUnlessSpelledInSource mode, we need to traverse the lambda
twice, but store whether we're matching in nodes spelled in source or
not.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/ASTMatchers/ASTMatchFinder.cpp | ||
---|---|---|
478–487 | ||
512–513 | ||
516 | ||
526 | Do we also need to traverse attributes of the lambda? | |
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp | ||
3069 | Do we have other test coverage for the rest of lambda matching, or should you add coverage for things like parameters, trailing requires clauses, etc? |
This patch causes practically infinite traversal times on code that contains deeply nested lambdas. I'll try to get a suitable repro, but could you maybe revert this in the meantime?
Actually, there's a very simple test case:
void f() { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { [] { }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }(); }
It looks like each lambda traversal triggers multiple traversals of the same AST fragment causing exponential growth of the traversal time.