We need the self metatype parameter to correctly lower
DynamicSelfType in IRGen, so plumb this through to all
calls of init accessors, and inside the prolog of an
init accessor definition.
This does not break the public ABI, because init
accessors are never public. Also for value types, the
metatype is thin, so it should not change generated
code.
For classes we need the metatype in the general case
because of `Self`, but hopefully in most cases the
init accessor can be inlined away and the value_metatype
instruction subject to dead code elimination.
Fixes rdar://problem/119822466.
`nonmutating set` gets a copy of "self" in `GetterSetterComponent`
which is expected for partial application of the setter but doesn't
work for "self" reference that `assign_or_init` instruction needs
to emit references to stored properties during lowering. We need to
make sure that "self" is always a reference to rootself of the
constructor before passing it to `assign_or_init`.
Resolves: https://github.com/apple/swift/issues/67827
Resolves: rdar://114433261
Default initializable init properties shouldn't prevent default
init synthesis and such properties without anything to initialize
should be considered by it.
Adjust DI to treat init accessor properties that have only 'accesses'
or no restrictions as if they are stored properties, this means that
if such property doesn't have a default initializer users would have
to reference it explicitly in their custom initializers.
We also need to suppress default init synthesis for such cases which
would be done in a followup commit.
Resolves: rdar://113401979
If stored property is covered by one or more init accessor property,
it's default initializable when at least one of the init accessor
properties has default value.
Per the clarification during the review thread, all properties with
init accessors (including those that do not initialize any underlying
storage) are part of the memberwise initializer.
Skip stored properties that are initialized via init accessors and
emit parameters/initializations in field order which allows us to
cover more use-cases.
If some property is initializable by one than one init accessor
let's not sythesize a memberwise initializer in that case because
it's ambiguous what is the best init accessor to use.
If init accessor initialize the same properties, let's emit them
in sequence and emit `destroy_addr` in-between to make sure that
there is no double initialization.
