The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
Now that SILGen change adds Unsafe access markers to addressors and
materializeForSet, we can use that as a sentinel to enable strict
verification everywhere.
This reverts commit 742e7fc583. This
causes other source compatibility regressions due to the extended exclusive access to
the existential (such as rdar://problem/39524104). A false-positive
exclusivity failure might lead to runtime errors, whereas the cases we
can't support previous to this patch can at least reliably be handled
statically.
This flag supports promoting KeyPath access violations to an error in
Swift 4+, while building the standard library in Swift 3 mode. This is
only necessary as long as the standard library continues to build in
Swift 3 mode. Once the standard library build migrates, it can all be
ripped out.
<rdar://problem/40115738> [Exclusivity] Enforce Keypath access as an error, not a warning in 4.2.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
Added new files, MemAccessUtils.h and MemAccessUtils.cpp to house the
new utility. Three functions previously in InstructionUtils.h move
here:
- findAccessedAddressBase
- isPossibleFormalAccessBase
- visitAccessedAddress
Rather than working with SILValues, these routines now work with the
AccessedStorage abstraction. This allows enforcement logic and SIL
pattern recognition to be shared across diagnostics and
optimization. (It's very important for this to be consistent).
The new AccessedStorage utility is a superset of the class that was
local to DiagnoseStaticExclusivity. It exposes the full set of all
recognized kinds of storage. It also represents function arguments as
an index rather that a SILValue. This allows an analysis pass to
compare/merge AccessedStorage results from multiple callee functions,
or more naturally propagate from callee to caller context.
closure lifetimes.
SILGen will now unconditionally emit
%cvt = convert_escape_to_noescape [guaranteed] %op
instructions. The mandatory ClosureLifetimeFixup pass ensures that %op's
lifetime spans %cvt's uses.
The code in DefiniteInitialization that handled a subset of cases is
removed.
Once the dust settled, this logic was only protecting a single occurrence of
memory access in SILGenLValue.cpp. It's simpler just to emit the begin/end
access markers in that case. The logic to work around it was nasty.
This statically guarantees that the access has no inner conflict within
its own scope.
IRGen will turn this into a "nontracking" access in which an
exclusivity check is performed for conflicts on an outer scope. However,
unlike normal accesses the runtime does not record the access, and the
access will not be checked for subsequent conflicts.
end_unpaired_access [no_nested_conflict] is not currently
supported. Making a begin_unpaired_access [no_nested_conflict] requires
deleting the corresponding end_unpaired_access. Future runtimes
could support this for verification by storing inline data in the
valud buffer. However, the runtime can never assume that a
[no_nested_conflict] begin_unpaired_access will have a corresponding
end_unpaired_access call without adding a new ExclusivityFlag for
that purpose.
Factor out the code to lower an individual key path component to be independent of overall KeyPathExpr lowering, so that we can soon reuse the same code paths to build property descriptors for resilient properties. NFC intended.
These accesses can't be recognized as obviously local temporaries in the
verification pass, so the only way to exhaustively verify exclusivity is by
added unenforced markers.
SILGen currently only emits unenforced markers under -verify-exlcusivity. Once
opaque values is the only supported SILGen mode, then we should turn the markers
on by default (SILGen should not have different modes of operation).
- Emit a withoutActuallyEscapingClosure partial apply
This is to convert an @noescape closure to an escaping closure.
This needs to be done in preparation of @noescape closure contexts
becoming trivial.
- Insert escaping to noescape conversions
- Fix SILGen for @noescape
- Postpone closure cleanups to outside the argument scope
- Apply postponement recursively for closures passed to subscripts
- Only skip applying escapeness conversions for Swift thick functions
- Fix parameter convention for noescape closures in thunks
Part of:
SR-5441
rdar://36116691
4b25945 changed codegen for lvalue OpenExistentialExprs so that the existential was not opened until the OpaqueValue's lvalue was evaluated, but this is incorrect—we need to open the dynamic type of the existential immediately since it can be used arbitrarily within the subexpression. This caused a regression when evaluating default argument generators on protocol extension methods (rdar://problem/37031037), and would become a bigger problem when we generalize the ability to open existentials.
When emitting an ignored expression, we try not perform a load of an lvalue if we can prove that loading has no observable side effects. Previously we based this on whether the components of the lvalue are physical, however some physical components (such as force unwrapping and key-paths) have side effects.
This commit introduces a new method to determine whether a component has side effects, and also adds an additional case to `emitIgnoredExpr` to avoid loading in cases where we have a force unwrap of an lvalue load (instead, if possible, try to emit the precondition using the lvalue address).
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
Collapse this routine down to its fundamental logic, removing unnecessary
hacks along the way. It's now self-documenting and robust.
The basic principle is that any special case should use the same
SILGen abstractions and utilities. The implementation should be
identical except where the special case is logically
distinct. i.e. the reason for the special case should be self-evident
from the code.
This is not NFC. Unnecessary borrow scopes are no longer emitted for
getters. More generally, there may have been some incidental behavior
specific to a corner cases that becomes more uniform now.
Use the LValue formal evaluation scope to destroy temporary lvalues that aren't
part of the expression's resulting value.
Disable an old hack that destroyed call site arguments after the call.
This is the first step in cleanup up LValue materialization.
This is not really the right fix if we want to have physically
addressed lvalues support bridging in general, but doing so
requires adding a new LValue component type and doing a bunch
more refactoring, so just hack in a narrow fix for now since
it only seems to occur in one case.
Fixes <rdar://problem/34913892>.
