[lldb] Fix GetParentIfClosure for async closures inside non-async functions #12026
+54
−6
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ctions
When computing the name of the parent function of a closure, LLDB takes
the demangled parent function Node and replaces it on the top level
"Global" demangle node. However, this logic was faulty in two ways:
1. A misplaced return made the "replace logic" only look at the fist
child of the Global node.
2. The new Global node was inheriting _all_ children from the original
Global node, which is wrong.
For example, an async closure inside a non-async function would have
this demangle tree:
```
Global
<Async Attributes>
<Explicit Closure>
<Parent Function>
```
By replacing the `Explicit Closure` with `Parent Function`, we were
creating another async function. The solution is to just create the
Global node from scratch, dropping most other nodes it may have had.
This begs the question of which other nodes could be there as a sibling
of the closure in the tree; given how none of the existing tests failed
with this patch, it seems safe to assume any such nodes are not too
important (until proven otherwise).
Author
|
@swift-ci test |
adrian-prantl
approved these changes
Dec 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When computing the name of the parent function of a closure, LLDB takes the demangled parent function Node and replaces it on the top level "Global" demangle node. However, this logic was faulty in two ways:
For example, an async closure inside a non-async function would have this demangle tree:
By replacing the
Explicit ClosurewithParent Function, we were creating another async function. The solution is to just create the Global node from scratch, dropping most other nodes it may have had. This begs the question of which other nodes could be there as a sibling of the closure in the tree; given how none of the existing tests failed with this patch, it seems safe to assume any such nodes are not too important (until proven otherwise).rdar://162788289