Make sure a dependency gets registered when a
direct lookup is fired off. This is necessary in
order to ensure that operator redeclaration
checking records the right dependencies (and any
future logic that might want to perform direct
operator lookups).
In doing so, this commit also removes the
compatibility logic for the old referenced name
tracker that would skip recording dependencies in
certain cases. This should be safe as the new
logic will record strictly more dependencies than
the old logic.
This is achieved in 3 steps:
1. CSApply detects assignments to property wrappers inside constructors, and produces an `inout` expr instead of a `load`, which it normally would because nonmutating setters take the `self` by-value. This is necessary becasue the assign_by_wrapper instruction expects an address type for its $1 operand.
2. SILGenLValue now emits the assign_by_wrapper pattern for such setters, ignoring the fact that they capture `self` by value. It also introduces an additional load instruction for the setter patrial_apply because the setter signature still expects a value and we now have an address (because of (1)).
3. DefiniteInitialization specifically ignores load instructions used to produce a `self` value for a setter referenced on assign_by_wrapper because it will be deleted by lowering anyway.
Resolves rdar://problem/60600911 and rdar://problem/52280477
Now that these are stored in the TypeResolution object itself, and all callers that mutate flags create a new resolution object, this data can be derived from the resolution itself.
Add the appropriate assertions to ensure that the now-redundant options parameters are being kept in sync so they can be retracted.
The eventual goal is to have TypeResolution requestified.
This augments #31023 to make sure CMake invokes the compiler checks
correctly -- this is needed to avoid errors in certain
configurations.
Addresses rdar://62339814
If a stored property has observers, the 'modify' coroutine body takes a
special form which directly yields the underlying storage and calls the
'didSet' and/or 'willSet' accessors.
However, if a property is 'dynamic', the 'modify' coroutine is synthesized
on-demand and it's SIL is serialized. It cannot reference the 'didSet'
or 'willSet' accessors, since they are private. Furthermore, an on-demand
accessor must also work if the property is overridden in a subclass.
So in this case, fall back to the more general 'modify' synthesis code,
which just calls the getter followed by the setter.
Fixes <rdar://problem/62339808>.
