Narrow the list of address producers that verification can "peek through"
to avoid trigger an assertion in the previous commit with
-enable-verify-exclusivity.
My previous attempt to strengthen this verification ignored the fact that a
projection or addressor that returns UnsafePointer can have nested access after
being passed as an @inout argument. After inlining, this caused the verifier to
assert.
Instead, handle access to an UnsafePointer as a valid but unidentified access. I
was trying to avoid this because an UnsafePointer could refer to a global or
class property, which we can never consider "Unidentified". However, this is
reasonably safe because it can only result from a _nested_ access. If a global
or class property is being addressed, it must already have its own dynamic
access within the addressor, and that access will be exposed to the
optimizer. If a non-public KeyPath is being addressed, a keypath instruction
must already exist somewhere in the module which is exposed to the optimizer.
Fixes <rdar://problem/41660554> Swift CI (macOS release master, OSS): SIL verification failed: Unknown formal access pattern: storage.
Modify IRGen to emit builtin access markers with an error flag in
Swift 3 mode.
KeyPath enforcement is required by user code in Swift 4+ mode, but is
implemented within the standard library. A [builtin] flag marks the
special case for access generated by Builtins so that they are
always enforced as an error regardless of the language mode.
This is necessary for Swift 4.2 because the standard library continues
to build in Swift 3 mode. Once the standard library build migrates,
this is all irrelevant.
This does not actually affect existing Swift 3 code, since the KeyPath
feature wasn't introduced until Swift 4.
<rdar://problem/40115738> [Exclusivity] Enforce Keypath access as an error, not a warning in 4.2.
Add dynamic enforcement of exclusive access when a KeyPath directly accesses a final
stored property on an instance of a class. For read-only projections, this begins and ends
the access immediately. For mutable projections, this uses the ClassHolder to perform
a long-term access that lasts as long as the lifetime of the ClassHolder.
rdar://problem/31972680
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
In AccessEnforcementSelection, treat passing a projection from a box to
a partial_apply as an escape to force using dynamic enforcement on the box.
This will now correctly use dynamic enforcement on variables that are taken
as inout and also captured by storage address in a closure:
var x = ...
x.mutatingMethod { ... use x ...}
but does pessimize some of our existing enforcement into dynamic since
access enforcement selection.
Ideally we would distinguish between escaping via an nonescaping closures
(which can only conflict with accesses that are in progress) and
escaping via escaping closures (which can conflict for any reachable code
after the escape)
