Each entry relates an attribute declaration to a list of all
declarations it's associated with together with a generator
function to acquire instance of the attribute value.
This attribute indicates that the given SILFunction has to be
added to "accessible functions" section and could be looked up
at runtime using a special API.
Type wrapper synthesis cannot reply on `getExecutableInit` to
determine whether initialization should use backing wrapper
call or not, it has to check whether the init expression exists.
I am adding this to make it easy to determine if a SILFunction that is not inout
aliasable is captured. This is useful when emitting certain types of
diagnostics like I need to emit with move only.
The current diagnostic that we are emitting is not perfect, but at least this
prevents us from saying that an error is not occuring here. I am going to file a
bug to track the QoI work of improving the diagnostic.
rdar://103313305
When opaque values are enabled, when yielding a value with an indirect
convention, a value whose type's category is "object" must be yielded.
Previously, if a value's type was loadable, an attempt was made to yield
a value whose type's category was "address". Here, that's fixed.
Additionally, handling for trivial types yielded via @in_guaranteed is
added.
Add TermInst::forwardedOperand.
Add SILArgument::forwardedTerminatorResultOperand. This API will be
moved into a proper TerminatorResult abstraction.
Remove getSingleTerminatorOperand, which could be misused because it's
not necessarilly forwarding ownership.
Remove the isTransformationTerminator API, which is not useful or well
defined.
Rewrite several instances of complex logic to handle block arguments
with the simple terminator result API. This defines away potential
bugs where we don't detect casts that perform implicit conversion.
Replace uses of the SILPhiArgument type and code that explicitly
handle block arguments. Control flow is irrelevant in these
situations. SILPhiArgument needs to be deleted ASAP. Instead, use
simple APIs like SILArgument::isTerminatorResult(). Eventually this
will be replaced by a TerminatorResult type.
If the emission of a function is delayed via `emitOrDelayFunction()`, then the function is recorded on a list of delayed functions. If the delayed function is later referenced, then the function moves from the delayed list to the "forced" list which will cause it to actually be emitted later. The implementation of `emitOrDelayFunction()` had a bug when called twice for the same delayable function - it would emit that function prematurely if the function moved to the forced list between the two invocations. Later, during forced function emission a multiple definitions of symbol diagnostic would be emitted since the function was not empty.
This issue could be triggered by `@_backDeploy` functions that have auxilary delayable helper functions (e.g. defer blocks). SILGen visits `@_backDeploy` functions twice (once for the copy of the function emitted into the client and once for the resilient copy of the function) so `emitOrDelayFunction()` is called twice for each of the helper functions and the helper functions could become referenced between the two calls.
The fix is to check for an existing entry in the forced functions list before delaying or emitting a delayable function.
Resolves rdar://102909684
Otherwise, we down the normal load [copy] path which will cause us to have a
tight exclusivity scope.
One thing to note is that if one accesses a field of a moveonly class one will
still get the tight exclusivity scope issue since SILGenLValue will emit the
moveonly class as a base of the field causing us to use the non-borrow codegen.
rdar://102746971
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
The definition of `Lowering::usesObjCAllocator()` was previously implemented in SILGen, which does not match the library membership of the declaration. The implementation of `SILSymbolVisitor` in the SIL library uses this and since SIL is a dependency of SILGen instead of vice-versa this resulted in a linker error.
This ensures that if we try to escape self or assign it to a variable, we
error since at the end of the deinit we always consume self and clean up its
variables.
I did not handle unique classes since it would have required a bit more surgery
around how deinits are handled and we do not need unique classes for our MVP.
rdar://102339259
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
This ensures that the address move checker does not have to perform any unsound
access scope expansions. One note is that the current approach does not work for
class member refs since in SILGenLValue, a class is considered a base of the
SILGenLValue access which is immediately evaluated (causing a copy) rather than
evaluated later at formal evaluation time. I have a few ways of working around
this issue but am going to fix it in a subsequent commit when I fix this for
classes and also read coroutines.
rdar://99616492
