Special-case Pattern Binding Decls Created by LLDB #37742
Merged
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
When LLDB wraps a user-defined expression in the REPL, it takes something like this
```
<expr>
```
and turns it into (very very abstractly)
```
var result
do {
result = <expr>
}
print(result)
```
In the process, it creates an implicit pattern binding and an implicit do block. Of these, only the implicit do is considered by ASTScope lookup to be relevant. This presents a problem when <expr> is or contains a closure, as the parameters of that closure are defined within a scope that will never be expanded. Thus,
```
> [42].map { x in x } // <- cannot find 'x' in scope
```
This patch provides the Swift half of the fix wherein we privilege pattern bindings created by the debugger and look through them to the underlying user expression when performing ASTScope expansion.
rdar://78256873
slavapestov
approved these changes
Jun 4, 2021
| @@ -40,6 +40,13 @@ static SourceLoc getLocAfterExtendedNominal(const ExtensionDecl *); | |||
|
|
|||
| void ASTScopeImpl::checkSourceRangeBeforeAddingChild(ASTScopeImpl *child, | |||
| const ASTContext &ctx) const { | |||
| // Ignore debugger bindings - they're a special mix of user code and implicit | |||
| // wrapper code that is too difficult to check for consistency. | |||
| if (auto d = getDeclIfAny().getPtrOrNull()) | |||
There was a problem hiding this comment.
We actually need source ranges to be in order for lookups to work correctly, though. Can you ignore the lldb-written part of the binding? It shouldn't have source locations anyway.
There was a problem hiding this comment.
I believe that’s what this does. When we expand the scopes for the binding’s initializer we’ll still run these checks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 LLDB wraps a user-defined expression in the REPL, it takes something like this
and turns it into (very very abstractly)
In the process, it creates an implicit pattern binding and an implicit do block. Of these, only the implicit do is considered by ASTScope lookup to be relevant. This presents a problem when
<expr>is or contains a closure, as the parameters of that closure are defined within a scope that will never be expanded. Thus,This patch provides the Swift half of the fix wherein we privilege pattern bindings created by the debugger and look through them to the underlying user expression when performing ASTScope expansion.
rdar://78256873