My recent refactoring of default arguments for the memberwise initializer
accidentally dropped support for getting a default argument when the
attached property wrapper has an init(). Reinstate that support,
fixing rdar://problem/52116923.
If a stored property has a didSet/willSet, we currently synthesize
the getter and the setter inside the parser. I want to get rid of
the parser's code path for doing that and consolidate all accessor
synthesis here in Sema.
Note that the parser did not synthesize a modify. This is now more
explicit in the code.
Also, we have to relax an assertion since addMemberToContextIfNeeded()
now gets called on declarations in local contexts.
Rewrite findOriginalPropertyWrapperInitialValue() to cope with composition
of property wrappers, making it more robust in the process.
Should fix rdar://problem/51576815.
When multiple property wrapper attributes are provided on a declaration,
compose them outside-in to form a composite property wrapper type. For
example,
@A @B @C var foo = 17
will produce
var $foo = A(initialValue: B(initialValue: C(initialValue: 17)))
and foo's getter/setter will access "foo.value.value.value".
When the backing storage of a wrapped property is default-initialized via the
property wrapper type's init(), don't count that as a direct initialization
of the backing storage for the purposes of constructing the memberwise
initializer. Instead, treat this case the same as if there were no initializer,
keying the form of the memberwise initializer off the presence of
init(initialValue:).
Turn the generic CustomAttrTypeRequest into a helper function and
introduce a FunctionBuilderTypeRequest that starts from a ParamDecl.
This has better caching characteristics and also means we only need to
do a single cache lookup in order to resolve the type in the normal path.
It also means we don't need as much parameterization in the cache.
In addition, check that the parameter has function type in the request,
not just when late-checking the attribute, and add a check that it isn't
an autoclosure.
The merge-modules phase doesn't have an active type checker, so we were bailing
out of property-wrapper queries before we had a chance to check the cache.
Move the check later, to the points where we actually need a type checker.
Fixes SR-10844 / rdar://problem/51484958.
Double-underscored names suggest the symbols aren't supposed to be used by framework
clients. This patch excludes the doc-comments of these symbols in swiftdoc files.
rdar://51468650
The determination of which type to use within the implicit memberwise
initializer for a wrapper property (between the original property type
and the wrapper type) could be affected by the synthesis of the call
to the default initializer. Rewrite the logic here to depend on
aspects of the AST that don't change with further type checking.
Add `llvm_unreachable` to mark covered switches which MSVC does not
analyze correctly and believes that there exists a path through the
function without a return value.
If an override B.f() is more visible than a base method A.f(), it is
possible that an override C.f() of B.f() cannot see the original method
A.f().
In this case, we would encounter linker errors if we referenced the
method descriptor or method dispatch thunk for A.f().
Make this work by treating B.f() as the least derived method in this
case, and ensuring that the vtable thunk for B.f() dispatches through
the vtable again.
Fixes <rdar://problem/48330571>, <https://bugs.swift.org/browse/SR-10648>.
Adds a NumStoredPropertiesQueries stat.
Adds a test case for an increasing number of lazy stored class
properties. Each property requires a formal access within the
initializer. This would manifest as cubic behavior in
AccessEnforcementOpts, which scales as O(1.5) in the above stat.
Replace most remaining uses of isRequirementSignatureComputed by
isRequirementSignatureComputing which uses Evaluator::hasActiveRequest
to detect if the requirements are currently being computed.
Replaces the explicit call to computeRequirementSignature from
validateDecl with a lazy getRequirementSignature. A side effect is that
the generic params of a ProtocolDecl are no longer computed from
validateDecl and must be computed lazily too.
When a property delegate type has a default initializer, use that to
implicitly initialize properties that use that delegate and do not have
their own initializers. For example, this would allow (e.g.), delegate
types like the DelayedImmutable and DelayedMutable examples to drop
the explicit initialization, e.g.,
```
@DelayedMutable var foo: Int
```
would be implicitly initialized via
```
$foo = DelayedMutable()
```
This is a simplistic implementation that does not yet propertly handle
definite initialization.
Fixes rdar://problem/50266039.
When a property with an attached delegate has less-than-internal visibility
and is initialized, don’t put it into the memberwise initializer because
doing so lowers the access level of the memberwise initializer, making it
fairly useless.
Longer term, it probably makes sense to have several memberwise initializers
at different access levels, so adding an initialized `private var` make
the memberwise initializer useless throughout the rest of the module.
Addresses rdar://problem/50266245.
The determination of whether a property is memberwise-initialized is
somewhat confused for properties that have synthesized backing properties.
Some clients (Sema/Index) want to see the declared properties, while others
(SILGen) want to see the backing stored properties. Add a flag to
`VarDecl::isMemberwiseInitialized()` to capture this variation.
This utility was defined in Sema, used in Sema and Index, declared in
two headers, and semi- copy-pasted into SILGen. Pull it into
VarDecl::isMemberwiseInitialized() and use it consistently.
