* add `DynamicFunctionRefInst` and `PreviousDynamicFunctionRefInst`
* add a common base class to all function-referencing instructions: `FunctionRefBaseInst`
* add `KeyPathInst`
* add `IndexAddrInst.base` and `IndexAddrInst.index` getters
* add `Instruction.visitReferencedFunctions` to visit all functions which are referenced by an instruction
The function describes the lifetime that variables of that type have by
default (unless otherwise annotated). This is done by looking at leaf
nodes until one that is not eager move is found, at which point the
lifetime is known to be lexical. Otherwise, the lifetime is eager move
(i.e. if every leaf is eager move).
Used RecursiveProperties to keep track of whether a type is lexical.
This is done in the usual way by OR'ing together whether components are
lexicial. The the values to be OR'd together come from primitives:
everything is non-lexical except reference types and resilient types
(because they could become reference types). Those values can however
be affected by user annotations: marking a class @_lexical makes the
value for that primitive lexical; markinig an enum or struct @_eagerMove
overrides the value obtained by OR'ing together its components and makes
it be non-lexical.
The reason why I am doing this is that in order to be able to use
PrunedLivenessBlocks with multiple elements, we can no longer rely on dead being
represented by a block not having any state, since a dead bit could have a
neighboring live bit.
That being said, the only place that this is used now is the current
PrunedLiveness implementation which only stores a single bit... but that still
at least exercises the code and lets us know that it works.
This is useful for making a form of PrunedLiveness that is sensitive to address
fields. I wired up the current PrunedLiveness to just use PrunedLiveBlocks with
num bits set to 1.
By default, whether a function argument's lifetime is determined by its
type. To allow that behavior to be overridden on an
argument-by-argument basis, the argument may have its own lifetime.
Include the parent `ModuleDecl` when serializing a `SILFunction` so that it is available on deserialized functions even though the full `DeclContext` is not present. With the parent module always available we can reliably compute whether the `SILFunction` comes from a module that was imported `@_weakLinked`.
Serialize the `DeclContext` member of `SILFunction` so that it can be used to look up the module that a function belongs to in order to compute weak import status.
Resolves rdar://98521248
Map store_borrow return_address with the destination, so that while cloning a store_borrow into a function w/o ownership,
users of store_borrow return address can be mapped with the lowered store's destination.
Add ScopedAddressOperand and ScopedAddressValue abstraction utilities
Introduce verification for store_borrow to validate its uses are correctly enclosed in their scope.
Include end_borrow/end_access as implicit uses while validating a borrow introducer
Add flow sensitive verifier rule for store_borrow/end_borrow pair
Make sure store_borrow is always to an alloc_stack
Make sure uses to store borrow location are via its return address only
This is exactly like copy_addr except that it is not viewed from the verifiers
perspective as an "invalid" copy of a move only value. It is intended to be used
in two contexts:
1. When the move checker emits a diagnostic since it could not eliminate a copy,
we still need to produce valid SIL without copy_addr on move only types since we
will hit canonical SIL eventually even if we don't actually codegen the SIL. The
pass can just convert said copy_addr to explicit_copy_addr and everyone is
happy.
2. To implement the explicit copy function for address only types.
The effect of declaring an import `@_weakLinked` is to treat every declaration from the module as if it were declared with `@_weakLinked`. This is useful in environments where entire modules may not be present at runtime. Although it is already possible to instruct the linker to weakly link an entire dylib, a Swift attribute provides a way to declare intent in source code and also opens the door to diagnostics and other compiler behaviors that depend on knowing that all the module's symbols will be weakly linked.
rdar://96098097
We had two notions of canonical types, one is the structural property
where it doesn't contain sugared types, the other one where it does
not contain reducible type parameters with respect to a generic
signature.
Rename the second one to a 'reduced type'.
