An expression macro can expand not just to code inside the function, but also to
a closure. Such a closure needs to be treated similar to any functions generated
from a freestanding macro: Its instructions should have locations that point
straight into the macro buffer. Instructions that are expanded into the same
function as the macro expansion can be represented using inline locations
pointing back to the macro expansion, but this is not an option for top-level
function declaration.
https://github.com/apple/swift/issues/65484
rdar://108618562
We haven't quite got the semantics we want implemented
for `discard` aka `_forget` statements. Allowing people
to use `_forget` in noncopyable types that have stored
properties that require destruction will not let us
implement it the way we'd like in the future without
source break. But, if the type only has "trivial" stored
properties with a no-op destruction, like `Int`, then we
can still provide utility for users like FileDescriptor
who just want to disable the deinit and have nothing
fancy stored in the type itself.
rdar://108877261
When `-unavailable-decl-optimization=stub` is specified, insert a call to
`_diagnoseUnavailableCodeReached()` at the beginning of the function to cause
it to trap if executed at run time.
Part of rdar://107388493
Specifically, I changed emitRValueForDecl and SILGenProlog to do the right
thing. I also added some tests.
Some notes:
1. We currently consider using a copyable field of a move only address type to
be a consume of that type. I am going to fix that in the next commit to make it
easier to understand.
2. I am going to need to write more tests/flesh out the behavior more. I am sure
there is more here.
rdar://105106470
Whenever we want to forward to a +1 value but don't need to destroy
the original memory, use isPlusOneOrTrivial.
This follows the existing naming scheme.
Fixes rdar://108001491 (SIL verification failed: Found mutating or
consuming use of an in_guaranteed parameter?!:
!ImmutableAddressUseVerifier().isMutatingOrConsuming(fArg))
In-memory values cannot be reused after deinitialization.
Add ManagedValue::isPlusOneOrTrivial() for situations where we want to
forward a value without destroying the original memory.
Fixes rdar://108001491 (SIL verification failed: Found mutating or
consuming use of an in_guaranteed parameter?!:
!ImmutableAddressUseVerifier().isMutatingOrConsuming(fArg))
In an earlier version of the ASTScope -> SILdebugScope translation a workaround
was put into place that would select the current debug scope if an ASTScope was
marked as ignoreInDebugInfo. Removing this workaround makes the translation more
predictable as it eliminated the dependency on the current SILBuilder state. The
property wrapper tests still pass without this.
This uncovers a situations with let bindings where the SIL instructions are
emitted RHS before LHS, which does violate the di-hole verifier. This is
addressed by relaxing the verifier for now.
rdar://108736443
This is a revert of the workaround for creating debug info for error variables
in b2109ab4db, while leaving the test added back then in place. The compiler
is now emitting debug info for the error pattern binding as it's supposed to and
after the recent migration to stricter debug scope generation, there are now
situations where the variable added for the workaround and the correct one are
in conflict.
rdar://108576484
When an accessor macro adds a non-observing accessor to a property, it
subsumes the initializer. We had previously modeled this as removing
the initializer, but doing so means that the initializer could not be
used for type inference and was lost in the AST.
Explicitly mark the initializer as "subsumed" here, and be more
careful when querying the initializer to distinguish between "the
initializer that was written" and "the initializer that will execute"
in more places. This distinction already existed at the
pattern-binding level, but not at the variable-declaration level.
This is the proper fix for the circular reference issue described in
rdar://108565923 (test case in the prior commit).
The reason to do this is that:
1. Otherwise, we do not emit markers when someone attempts to consume the let.
We need the no_consume_or_assign to be there.
2. We need to insert assign_but_not_consuming so that DI can properly check lets
that are conditionally initialized and convert them to
initable_but_not_consuming.
I included a full definite_init SIL test that validates that we get the correct
codegen after DI in this case and emit the appropriate error as well.
rdar://108511534
The reason why I am doing this is that otherwise if one has a function that
takes both a guaranteed and an owned parameter, we will break OSSA invariants
since the load [take] will invalidate the load_borrow. So instead, we put in a
load_borrow knowing that the move checker will convert it to a load_borrow
assuming that the two pass exclusivity checking.
NOTE: Because of some missing functionality in subsequent tests, I had to
disable one test (moveonly_escaping_definite_initialization.swift) and also add
some checks for copy of noncopyable object errors. They will go away in the next
2 commits.
rdar://108510987
Before this patch the parents of SILDebugScopes representing macro expansions
were missing the inlinedAt field, which resulted in incorrent LLVM IR being
produced. This is fixed by first computing the inlined call site for a macro
expansion and then computing the nested SILDebugScope for the ASTScope of the
expanded nodes; adding the inlinedAt field to all of levels of parent scopes.
rdar://108323748
Normally, if we project from a mutable class ivar or global variable, we'll
load a copy in a tight access scope and then project from the copy, in order to
minimize the potential for exclusivity violations while working with classes and
copyable values. However, this is undesirable when a value is move-only, since
copying is not allowed; borrowing the value in place is the expected and only possible
behavior. rdar://105794506
When expanding a conformance macro, the generated extension decls are added to
the TopLevelDecls vector of the synthesized file unit to expose them to
sf->getSynthesizedFile()->getTopLevelDecls(). There are two problems with this:
1. These decls are also visited via visitAuxiliaryDecls() for the purpose of
type checking. This causes problems in code generation because the extensions
are visited separately, and because SIL and IRGen assume nested auxiliary decls
are members.
2. SILGen only emits top-level decls directly from the source file rather than its
synthesized file. Auxiliary decls are visited here, but this doesn't work for
nested conformance macros because the attached-to decl is not at the top-level,
so macro-generated conformances for nested types never emit their descriptor.
To fix this in the short term, visit top-level decls in the synthesized file that are
generated by conformance macros, and skip auxiliary extension decls when emitting type
members. This fix is narrowly scoped to only impact macros, but in the future this
warrants a more structural fix to better handle top-level decls in the synthesized file.
I ran into this while fixing the parent commit when attempting to add the
interpreter test in this commit into the aforementioned parent commit.
rdar://107974302
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
