I tried to make them shorter and standardized on "; later accesses could race"
as the mark on a diagnostic that the problem was that a race was occuring
(before we had several small different variations).
Before the previous patch, we were just getting lucky on macOS due to UB. Now
that the UB is fixed, we correctly crash without this commit since we were not
pattern matching the simple case of a local value that was transferred and used
later.
The specific semantics is if we assign into a transferring parameter's field,
then we "merge" src's value into the transferring parameter, so we
conservatively leave the region of the transferring parameter alone. If we
assign over the entire transferring parameter, we perform an assign fresh since
any value that used to be in the transferring parameter cannot reference
anything in its new value since they are all gone.
By default it lowers the builtin to an `alloc_vector` with a paired `dealloc_stack`.
If the builtin appears in the initializer of a global variable and the vector elements are initialized,
a statically initialized global is created where the initializer is a `vector` instruction.
Specifically:
1. If the value is transferred such that it becomes part of an actor region, the
value is permanently part of the actor region as one would normally have.
2. If the value is just used in an async let or is used by a nonisolated async
function within the async let then while the async let is alive it cannot be
used. But once the async let has been awaited upon, we allow for it to be used
again.
rdar://117506395
In regular swift this is a nice optimization. In embedded swift it's a requirement, because the compiler needs to be able to specialize generic deinits of non-copyable types.
The new de-virtualization utilities are called from two places:
* from the new DeinitDevirtualizer pass. It replaces the old MoveOnlyDeinitDevirtualization, which is very basic and does not fulfill the needs for embedded swift.
* from MandatoryPerformanceOptimizations for embedded swift
Functions which which consume their arguments will release them on any
branches where the arguments are unused. Users of `@_effects(readnone)`
and `@_effects(readonly)` may not consider this when annotating their
functions. Require that functions annotated thus are also annotated
@_effects(releasenone).
In order to support this, adjust SILFunctionBuilder to allow distinct
non-custom effects and to interpret such "conflicting" guarantees to
provide the strongest guarantee. For example, annotating a function
both `@_effects(readnone)` and `@_effects(releasenone)` is equivalent to
only annotating it `@_effects(readnone)`.
Specifically, we previously emitted a "compiler doesn't understand error", so we
were always emitting an error appropriately. This just gives a better error
message saying instead that the compiler did understand what happened and that
one cannot apply consume to globals or escaping captures.
https://github.com/apple/swift/issues/67755
rdar://112561671
Before this change, if a global variable is required to be statically initialized (e.g. due to @_section attribute), we don't allow its type to be a struct, only a scalar type works. This change improves on that by teaching MandatoryPerformanceOptimizations pass to inline struct initializer calls into initializer of globals, as long as they are simple enough so that we can be sure that we don't trigger recursive/infinite inlining.
This is similar to our ban on partial consuming a value for this release. The
reason for this is that, one can achieve a similar affect as partial consumption
via a consumption of the entire value and then a partial reinitialization. Example:
```swift
struct X : ~Copyable { var i = 5, var i2 = Klass() }
var x = X()
_ = consume x
x.i = 5
```
in the case above, we now have a value that is in a partially initialized state.
We still allow for move only types to have their fields initialized as long as
there is an intervening init.
rdar://111498740
Attribute @_silgen_name is today only allowed to be used on functions, this change allows usage on globals as well. The motivation for that is to be able to "forward declare" globals just like it's today possible to do with functions (for the cases where it's not practical or convenient to use a bridging header).
Separately, this change also adds a @_silgen_name(raw: ...) syntax, which simply avoids mangling the name (by using the \01 name prefix that LLVM uses). The motivation for that is to be able to reference the "magic Darwin linker symbols" that can be used to look up section bounds (in the current dylib/module) -- those symbols don't use the underscore prefix in their mangled names.
The reason why I am doing this is that this was not part of the original
evolution proposal (it was called an extension) and after some discussion it was
realized that partial consumption would benefit from discussion on the forums.
rdar://111353459
The value `self` is mutable (i.e., var-bound) in
a `consuming` method. Since you're allowed to
reinitialize a var after consuming, that means
you were also naturally allowed to reinitialize
self after `discard self`. But that capability was
not intended; after you discard self you shouldn't
be reinitializing it, as that's probably a mistake.
This change makes reinitialization of `self`
reachable from a `discard self` statement an error.
rdar://106098163
As part of SE-390, you're required to write either:
- `consume self`
- pass self as a `consuming` parameter to a function
- `discard self`
before the function ends in a context that contains a
`discard self` somewhere. This prevents people from accidentally
invoking the deinit due to implicit destruction of `self` before
exiting the function.
rdar://106099027
* Add @_used and @_section attributes for global variables and top-level functions
This adds:
- @_used attribute that flags as a global variable or a top-level function as
"do not dead-strip" via llvm.used, roughly the equivalent of
__attribute__((used)) in C/C++.
- @_section("...") attribute that places a global variable or a top-level
function into a section with that name, roughly the equivalent of
__attribute__((section("..."))) in C/C++.
this also fixes a bug where sometimes we simply emit
'consumed here' twice and other times we'd said 'other
consume here' for the same "consumed more than once"
message. so I went through and changed all of the 2nd
consumes into "consumed again".
rdar://109281444
- refer to a "consuming use" as simply a "consume", to reserve "use" for non-consuming uses.
- refer to "non-consuming uses" as just a "use".
- don't call it a "user defined deinit" and instead a "deinitializer" to match Sema
- be specific about what binding a closure is capturing that is preventing consumption.
rdar://109281444
