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.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
Default arguments for `init accessors` are not fully supported
at the moment, so we shouldn't attempt to synthesize them in
Sema just to crash during linking.
When writing an @objc subclass of an @objcImplementation class, implicit initializers in the subclass were treated as overriding the *implementation decl*, not the *interface decl*, of the initializer in the superclass. This caused Swift to incorrectly compute the visibility of the superclass initializer and omit an `override` keyword from the module interface when one would definitely be necessary.
Correct this oversight by looking up the interface decl matching the superclass implementation in `collectNonOveriddenSuperclassInits()`.
A class that uses @objcImplementation but does not explicitly declare any designated initializers previously did not override the superclass initializers, so its stored properties would not be initialized. Opt these classes into that logic and adjust it to add the initializers to the @objcImplementation extension instead of the ClassDecl itself.
Fixes rdar://105008242.
Swift interfaces have both attribute and all publicly accessible
synthesized members, which means that the synthesis needs to be
taught to lookup existing synthesized declarations for `$storage`,
`$Storage`, and `init(storageWrapper:)` if request comes for
declaration that belongs to a Swift interface file.
The request is updated to return attribute, wrapper declaration,
the declaration its attached to and whether or not it has been
inferred (opposite to being declared directly).
https://github.com/apple/swift/pull/42041 introduced a centralized mechanism for adding the `nonisolated` attribute to synthesized decls but did not clean up the existing code that was already doing so for `Hashable` conformances.
Resolves rdar://102106591
Adding a type wrapper attribute on a protocol does two things:
- Synthesizes `associatedtype $Storage` declaration with `internal` access
- Synthesizes `var $storage: <#Wrapper#><Self, Self.$Storage>` value requirement
ObjC classes which have only factory and convenience initializers cannot allow their convenience inits to be inherited. To provide these classes with a reliable opt-out, tweak support for @_hasMissingDesignatedInitializers so that it affects ObjC classes even if they’re in the same module as one another.
Fixes rdar://48511013.
If there are no type wrapper ignored stored properties, the
compiler would synthesize a special public initializer that
allows to initialize a wrapped type by providing a fully
initialized wrapper instance.
Emit a call to a helper function that determines whether the symbols associated with the declaration referenced in the `#_hasSymbol(...)` condition are non-null at runtime. An upcoming change will emit a definition for this function during IRGen.
Resolves rdar://100130015
It was done in `maybeAddTypeWrapperDefaultArg` before because
user-defined initializers weren't supported but now property
initializers need to be subsumed earlier to make sure that
SILGen doesn't try to emit them into user-defined initializers.
If a stored property would be in a default memberwise initializer
it would be added to the `init` synthesized for a type wrapped type
as well i.e. a `let` property without a default.
Since properties with property wrappers are not supported, default
init synthesis needs to handle them as well by using correct interface
type depending on outer wrapper capabilities and setting correct
default expression.
Synthesize an `init` declaration which is going to initialize
type wrapper instance property `$_storage` via user provided
values for all stored properties.
Compiler cannot synthesize regular memberwise or default
initializers for type wrapped types because stored properties
of such a type cannot be accessed directly.
A special initializer would be synthesized instead, it is going
to initialize `$_storage` variable and handle default initialization
of stored properties.
MSVC isn't seeing that `CheckDefaultInitializer` is declared and being
implicitly captured by reference by the closure going into the
`forEachVariable`.
Capturing `HasStorage` and `CheckDefaultInitializer` explicitly.
