Map the lifetime dependencies described in terms of the formal AST-level parameters
to the correct parameter(s) in the lowered SIL function type. There can be 0, 1,
or many SIL parameters per formal parameter because of tuple exploding. Also,
record which dependencies are on addressable parameters (meaning that the dependency
includes not only the value of the parameter, but its specific memory location).
Disable inference diagnostics because the AST output makes implicit initializers
explicit.
Enable parsing the @lifetime declaration syntax to handle explicit annotations
on declarations.
Lifetime dependencies in SIL tests continue to be represented as a type modifier on the target.
As before, they are represented as a LifetimeDependentTypeRepr in the AST.
@lifetime(target: source1, source2...) where target can be any
parameter or 'self'. We cannot have @lifetime attributes with duplicate targets.
Also, update the internal data structures. Previously LifetimeEntry stored
pairwise (target, source) dependencies. Now, LifetimeEntry will store an optional
target descriptor and an array of source descriptors.
Lifetime dependencies will now be represented with @lifetime attribute in the language.
dependsOn is a type modifier and was represented as a LifetimeDependentTypeRepr in the AST.
I am deleting dependsOn syntax parsing support and retaining LifetimeDependentTypeRepr support.
We may want to represent lifetime dependencies in a function type with a type attribute in the future.
If we use a decl attribute instead, then support for LifetimeDependentTypeRepr can be deleted.
We need this at least until we have 'dependsOn(self)' syntax.
When 'self' is nonescapable and the result is 'void', assume that 'self' depends
on a single nonescapable argument.
Create two versions of the following functions:
isConsumedParameter
isGuaranteedParameter
SILParameterInfo::isConsumed
SILParameterInfo::isGuaranteed
SILArgumentConvention::isOwnedConvention
SILArgumentConvention::isGuaranteedConvention
These changes will be needed when we add a new convention for
non-trivial C++ types as the functions will return different answers
depending on whether they are called for the caller or the callee. This
commit doesn't change any functionality.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Allow lifetime depenendence on types that are BitwiseCopyable & Escapable.
This is unsafe in the sense that the compiler will not diagnose any use of the
dependent value outside of the lexcial scope of the source value. But, in
practice, dependence on an UnsafePointer is often needed. In that case, the
programmer should have already taken responsibility for ensuring the lifetime of the
pointer over all dependent uses. Typically, an unsafe pointer is valid for the
duration of a closure. Lifetime dependence prevents the dependent value from
being returned by the closure, so common usage is safe by default.
Typical example:
func decode(_ bufferRef: Span<Int>) { /*...*/ }
extension UnsafeBufferPointer {
// The client must ensure the lifetime of the buffer across the invocation of `body`.
// The client must ensure that no code modifies the buffer during the invocation of `body`.
func withUnsafeSpan<Result>(_ body: (Span<Element>) throws -> Result) rethrows -> Result {
// Construct Span using its internal, unsafe API.
try body(Span(unsafePointer: baseAddress!, count: count))
}
}
func decodeArrayAsUBP(array: [Int]) {
array.withUnsafeBufferPointer { buffer in
buffer.withUnsafeSpan {
decode($0)
}
}
}
In the future, we may add SILGen support for tracking the lexical scope of
BitwiseCopyable values. That would allow them to have the same dependence
behavior as other source values.
