This is an archive of the discontinued LLVM Phabricator instance.

[ASTMatchers] Ensure that we can match inside lambdas
ClosedPublic

Authored by steveire on Dec 22 2020, 4:24 AM.

Details

Summary

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.

Diff Detail

Event Timeline

steveire requested review of this revision.Dec 22 2020, 4:24 AM
steveire created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 22 2020, 4:24 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaron.ballman added inline comments.Jan 4 2021, 9:44 AM
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?

steveire updated this revision to Diff 314446.Jan 4 2021, 1:32 PM
steveire marked 2 inline comments as done.

Update

steveire marked an inline comment as done.Jan 4 2021, 1:32 PM
steveire added inline comments.
clang/lib/ASTMatchers/ASTMatchFinder.cpp
526

At least RAV doesn't do so. It would be a new feature which is orthogonal to this MR/patch.

clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
3069

Yep, there's other lambda-related tests higher up in this test function.

aaron.ballman accepted this revision.Jan 5 2021, 5:50 AM

LGTM

clang/lib/ASTMatchers/ASTMatchFinder.cpp
526

Okay, SGTM

This revision is now accepted and ready to land.Jan 5 2021, 5:50 AM
alexfh added a subscriber: alexfh.Jan 27 2021, 11:07 AM

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?

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.