Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
This patch replaces the stateful generation of SILScope information in
SILGenFunction with data derived from the ASTScope hierarchy, which should be
100% in sync with the scopes needed for local variables. The goal is to
eliminate the surprising effects that the stack of cleanup operations can have
on the current state of SILBuilder leading to a fully deterministic (in the
sense of: predictible by a human) association of SILDebugScopes with
SILInstructions. The patch also eliminates the need to many workarounds. There
are still some accomodations for several Sema transformation passes such as
ResultBuilders, which don't correctly update the source locations when moving
around nodes. If these were implemented as macros, this problem would disappear.
This necessary rewrite of the macro scope handling included in this patch also
adds proper support nested macro expansions.
This fixes
rdar://88274783
and either fixes or at least partially addresses the following:
rdar://89252827
rdar://105186946
rdar://105757810
rdar://105997826
rdar://105102288
This leads to an assertion failure in IRGen. A `guard let foo = foo` statement
needs to introduce a new lexical scope so the newely introduced binding can be
distinguished from the one it shadows.
rdar://86579287
This was matching the wrong `throw` as the scope was incorrect. Correct
the scope which allows us to match the correct `throw` and enable the
test on Windows.
While here, add an additional check for the `destroy_addr`,
`dealloc_stack` to match the regular exit which is duplicated in the
throwing block. Add an additional check to ensure that we do not escape
the bounds of the function.
Thanks to @adrian-prantl for helping ensure that the changes here are
valid!
Fixes: SR-14267
The debugger relies on function arguments and local variables to be in different
scopes in order to disambiguate between local variables that shadow function
arguments.
rdar://83769198
This fixes an ambiguity (that leads to a crash further down the pipeline) when
compiling optional unwrap bindings that bind the same variable name.
rdar://73490741
(cherry picked from commit 173c0b4657)
Before this patch every Swift function would contain a top-level
DW_TAG_lexical_scope that didn't provide any useful information, used extra
space in the debug info and prevented local variables from showing up in virtual
async backtraces.
This is a follow-up to e9d557ae28. The
debug_value for the guard let binding is introduced by SGF.emitStmtCondition(),
so we also need to enter the debug scope before running that function.
rdar://74538257
* rename -sil-print-only-function to -sil-print-function and -sil-print-only-functions to -sil-print-functions
* to print single functions, don't require -Xllvm -sil-print-all. It's now sufficient to use e.g. -Xllvm -sil-print-function=<f>
But it's still possible to select functions with -sil-print-function(s) for other print options, -sil-print-after.
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>.
I am doing this so I can start writing DI tests without this lowering occuring.
There never was a real reason for this code to be in DI beyond convenience. Now
it just makes writing tests more difficult. To prevent any test delta, I changed
all current DI tests to run this pass after DI.
