For any operation that can throw an error, such as calls, property
accesses, and non-exhaustive do..catch statements, record the thrown
error type along with the conversion from that thrown error to the
error type expected in context, as appropriate. This will prevent
later stages from having to re-compute the conversion sequences.
Parse typed throw specifiers as `throws(X)` in every place where there
are effects specified, and record the resulting thrown error type in
the AST except the type system. This includes:
* `FunctionTypeRepr`, for the parsed representation of types
* `AbstractFunctionDecl`, for various function-like declarations
* `ClosureExpr`, for closures
* `ArrowExpr`, for parsing of types within expression context
This also introduces some serialization logic for the thrown error
type of function-like declarations, along with an API to extract the
thrown interface type from one of those declarations, although right
now it will either be `Error` or empty.
Previously both `AreAllStoredPropertiesDefaultInitableRequest`
and `HasMemberwiseInitRequest` checked only "current" properties
of the type but macro expansions can add new stored and/or
init accessor properties that affect this logic so we need to
make sure that macro expansions happen and new properties are
accounted for.
Note that the original idea was to use `getStoredProperties()`
but that runs into multiple circularity issues related to lazy
properties.
Resolves: rdar://112153201
Default initializable init properties shouldn't prevent default
init synthesis and such properties without anything to initialize
should be considered by it.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
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.
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.
