SILGen: Introduce a new debug scope for GuardStmts [5.4] #35333
Conversation
|
@adrian-prantl Please take a look. |
slavapestov
changed the title
|
Build failed |
|
Build failed |
|
Build failed |
|
Build failed |
lib/SILGen/SILGenFunction.h
Outdated
| /// | ||
| /// The boolean tracks whether this is a 'guard' scope, which should be | ||
| /// popped automatically when we leave the innermost BraceStmt scope. | ||
| std::vector<std::pair<bool, const SILDebugScope *>> DebugScopeStack; |
There was a problem hiding this comment.
Maybe use an llvm::PointerIntPair<const SILDebugScope *, 1>?
| @@ -590,23 +593,29 @@ class LLVM_LIBRARY_VISIBILITY SILGenFunction | |||
| StringRef getMagicFunctionString(); | |||
|
|
|||
| /// Enter the debug scope for \p Loc, creating it if necessary. | |||
There was a problem hiding this comment.
Perhaps add something like:
/// \arg isGuardScope marks a scope introduced by a guard let statement. Guard let may used to unwrap an optional and bind it to the same name (as in guard let x = x!). All guard let scopes are popped when their parent lexical scope is popped from DebugScopeStack.
|
Looks like @DougGregor needs to sign off for this PR to be mergeable. |
|
Looks like you are running into the non-contiguous scope SIL verifier. |
|
Unfortunately its output on the bot is useless since |
|
If you can post the SIL output (with scopes!) we can see why that is. It should be fairly obvious. |
|
Thanks for the review, all the suggested changes sound reasonable. I'll nominate the PR once I apply your changes and fix the swiftpm issue. |
slavapestov
force-pushed
the
debug-scope-guard-stmt-5.4
branch
2 times, most recently
from
069e01a to
cbe3ea7
Compare
A GuardStmt can shadow bindings from outer scopes, so make sure we actually create a new debug scope here. Note that we push the scope, but pop it when the next innermost debug scope ends. To keep track of this I added a new bit of state to the debug scope stack, indicating that this scope originated from a GuardStmt. Ideally, debug info would rely on ASTScope which is the canonical source of truth for this information. For now, this is a spot fix. I filed <rdar://problem/72954242> to track implementing the longer term solution. Fixes <rdar://problem/72900354>.
slavapestov
force-pushed
the
debug-scope-guard-stmt-5.4
branch
from
cbe3ea7 to
e9d557a
Compare
|
@swift-ci Please test |
|
Build failed |
|
@swift-ci Please test macOS |
AnthonyLatsis
added
swift 5.4
🍒 release cherry pick
A GuardStmt can shadow bindings from outer scopes, so make sure
we actually create a new debug scope here.
Note that we push the scope, but pop it when the next innermost
debug scope ends. To keep track of this I added a new bit of state
to the debug scope stack, indicating that this scope originated
from a GuardStmt.
Ideally, debug info would rely on ASTScope which is the canonical
source of truth for this information. For now, this is a spot fix.
I filed rdar://problem/72954242 to track implementing the longer
term solution.
Fixes rdar://problem/72900354.