Non-‘@objc’ ‘dynamic’ has been allowed since Swift 5, but there’s no
reason to tie it to the language mode (Swift >= 5).
Fixes rdar://problem/50348013.
When a class has missing vtable entries, we don’t allow it to be subclassed. This is unnecessarily restrictive for resilient classes, and @_implementationOnly imports now make missing vtable entries much more common. This commit carves out an exception to that rule for resilient classes.
Fixes <rdar://problem/50902125>.
A number of tests exercise features only available in Apple OSes that
shipped with Swift 5.0 in the OS; this includes the following versions:
- macOS 10.14.4
- iOS 12.2
- tvOS 12.2
- watchOS 5.2
Previously these tests were restricted to running on macOS only, with
an explicit -target x86_64-apple-macosx10.14.4. To get better test
coverage, add a new %target-stable-abi-triple substitution which
expands to a triple with the correct OS version on all Apple platforms.
On non-Apple platforms, this is the same as %target-variant-triple,
but for now any test that uses this exercises Apple platform features
anyway.
One caveat is that since iOS 12.2 does not have a 32-bit slice, we
have to skip any tests that use -target %target-stable-abi-triple
on this platform. A new swift_stable_abi feature flag can be tested
with 'REQUIRES: swift_stable_abi'. To get maximum test coverage,
I split off a 'stable_abi' version of a few tests that build with both
an old and new deployment target. This allows the old deployment
target case to still be tested on 32-bit iOS.
I thought it would be useful to allow some uses of a module to be
'@_implementationOnly' and others to not be in case someone wanted to
change from one to the other gradually, but it turns out that if
you're trying to /make/ an import implementation-only, you want to
know everywhere you used it.
rdar://problem/50748157
The GSB should avoid triggering declaration validation where
possible, to avoid problems resulting from circularity and as
a general performance rule-of-thumb.
This last call was there to catch self-recursive protocol
typealiases. However, we can diagnose this problem elsewhere,
which allows us to emit a more accurate diagnostic as well.
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.
If we haven't validated the declaration yet, the 'witnesses @objc
requirement' check would immediately fail. Move the validateDecl()
call to matchWitness() to fix this.
Fixes <rdar://problem/49482328>, <https://bugs.swift.org/browse/SR-10257>.
When the property delegate type overrides the delegate value by providing
a delegateValue property, name the backing storage $$foo and make it private.
When a custom attribute is given a direct initializer, save and re-use
the initializer context we create so that it can be associated with the
enclosing pattern binding. Fixes assertions involving explicit closures
in property delegates.
The initialization of an instance property that has an attached
property delegate involves the initial value written on the property
declaration, the implicit memberwise initializer, and the default
arguments to the implicit memberwise initializer. Implement SILGen
support for each of these cases.
There is a small semantic change to the creation of the implicit
memberwise initializer due to SE-0242 (default arguments for the
memberwise initializer). Specifically, the memberwise initializer will
use the original property type for the parameter to memberwise
initializer when either of the following is true:
- The corresponding property has an initial value specified with the
`=` syntax, e.g., `@Lazy var i = 17`, or
- The corresponding property has no initial value, but the property
delegate type has an `init(initialValue:)`.
The specific case that changed is when a property has an initial value
specified as a direct initialization of the delegate *and* the
property delegate type has an `init(initialValue:)`, e.g.,
```swift
struct X {
@Lazy(closure: { ... })
var i: Int
}
```
Previously, this would have synthesized an initializer:
```swift
init(i: Int = ???) { ... }
```
However, there is no way for the initialization specified within the
declaration of i to be expressed via the default argument. Now, it
synthesizes an initializer:
```swift
init(i: Lazy<Int> = Lazy(closure: { ... }))
```
When a property has an attached property delegate, a backing storage
property of the corresponding delegate type will be
synthesized. Perform this synthesis, and also synthesize the
getter/setter for the original property to reference the backing
storage property.
A property with an attached delegate can be initialized in one of two ways:
* By directly specifying initialization arguments on the attribute,
e.g., "@SomeDelegate(x: 17, y: 42) var a".
* By initializing the original property itself, which goes through the
delegate type's init(initialValue:) initializer, e.g.,
"@Lazy var x = 17".
Implement support for both forms of initialization, including type
inference and checking for inconsistencies (e.g., if the annotation on
the property type doesn't match what the delegate type would
provide).
A custom attribute can be resolved to a property delegate type. Allow
this for property declarations (only), and diagnose the various places
where properties cannot have property delegates.
Obj-C subscripts don’t work on class objects, but you can declare class methods with the appropriate names. We don’t want to half-support this. Emit an error if you try to write “@objc class subscript” and test that we don’t import the methods as subscripts.
