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.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
The code to remove these subsumed properties was part of creating the
memberwise initializer declaration, which could lead to
inconsistencies with the newly-introduced request for gathering the
memberwise-initialized properties. Move the code into the computation
of the list of memberwise-initialized properties.
Also update a few more places that were effectively recomputing the
set of memberwise-initialized properties themselves over to the
request.
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.
