Details
- Reviewers
sammccall - Commits
- rG4718ec01669b: [clangd] Avoid recursion in TargetFinder::add()
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/unittests/FindTargetTests.cpp | ||
---|---|---|
790 | This test case is not strictly related to the bug, but it adds test coverage for a scenario that I think is important, and that could be broken if we took a different approach to fixing this bug (see my comments on the issue for details). |
clang-tools-extra/clangd/FindTarget.cpp | ||
---|---|---|
376 | rather than introducing a new member for CurrentlyProcessing, can't we just get away with checking the decl we are going to jump on here (and probably in namespace alias case) are the same (or maybe a parameter to add function indicating the parent/previous)? it is definitely cleaner to have a member rather than checking individually but we have other types of ast nodes we can be currently processing (statements, nested namespecifiers etc. and they are not covered by this member. so it is a little bit confusing conceptually. |
clang-tools-extra/clangd/FindTarget.cpp | ||
---|---|---|
376 | It takes a few steps to get back the recursive declaration:
So, we'd have to propagate the "previous decl" into add(QualType) and make it a member of the TypeVisitor at least, to be able to check there. |
Doh, I really thought we'd get away without an explicit recursion guard here.
But the example is compelling, so this seems like the right approach. Unfortunately, I think we're going to end up needing to add allocations too...
clang-tools-extra/clangd/FindTarget.cpp | ||
---|---|---|
333 | I don't think a single pointer is going to cut it here - can't we construct a mutually-recursive example so that the "wrong" decl is on always on top of the stack and we never bail out? We probably want a SmallDenseMap Seen or something? (And then we no longer need to look up in the actual result set). Couple of related refinements:
| |
333 |
This is just for implementation convenience, we could reverse the order by rearranging the code somehow. However this seems fragile to me - I'm thinking about the cases where we reassign D in the function of the body here, and so end up reporting some other declaration instead (which may not be in the cycle). |
Whats the purpose in tracking this? Is the Decls lookup not enough?