When a non-@objc witness matches an @objc requirement except for
@objc-ness, treat it the same way whether it's an optional requirement
or not, except that it's a warning for the optional case. Should
finish off rdar://problem/25159872.
It's a common mistake to mistype a declaration that is intended to
satisfy an optional requirement. In such "near misses", we want to
warn about the mistake and give the user options to either fix the
declaration or suppress the warning. Approach this problem be walking
over all of the members of each nominal type declaration or extension
therefore and looking to see if there are any members remaining that
(1) are similarly-named to an unfilfilled optional requirement of a
protocol whose conformance is attributed to that nominal type
declaration or extension,
(2) are not witnesses to another optional requirement,
(3) haven't explicitly suppressed the warning (e.g., by adding
explicit "private" or explicit "@nonobjc"), and
(4) have a useful suppression mechanism.
In addition to the suppression mechanisms described in (3), one can
suppress this warning by moving the declaration to an(other)
extension. This encourages a programming style where one breaks an
interface into extensions each implement conformance to one
protocol. Note that we encode the various cases where one cannot move
the declaration to another extension (e.g., one cannot move a
designated initializer or stored property out of a class declaration)
and suppress the warning when there's no way for the user to cope with
it.
Each warning produced by this diagnostic can have a bunch of notes on
it for various courses of action. For example:
t2.swift:7:14: warning: instance method 'doSomething(z:)' nearly
matches optional requirement 'doSomething(x:)' of protocol 'P1'
@objc func doSomething(z: Double) { }
^
t2.swift:7:14: note: rename to 'doSomething(x:)' to satisfy this
requirement
@objc func doSomething(z: Double) { }
^
x
t2.swift:7:14: note: move 'doSomething(z:)' to an extension to silence
this warning
@objc func doSomething(z: Double) { }
^
t2.swift:7:14: note: make 'doSomething(z:)' private to silence this
warning
@objc func doSomething(z: Double) { }
^
private
t2.swift:2:17: note: requirement 'doSomething(x:)' declared here
optional func doSomething(x: Int)
^
It's a *lot* of detail, but is intended to cover the various choices
available to the user: Fix-It to the names of the requirement (for
naming-related mistakes) or suppress via various mechanisms. Combining
notes means losing Fix-Its, while dropping notes can lead users to
non-optimal solutions.
This is more of rdar://problem/25159872.
When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
Simplify and improve the checking of @objc names when matching a
witness to a requirement in the @objc protocol. First, don't use
@objc-ness as part of the initial screening to determine whether a
witness potentially matches an @objc requirement: we will only reject
a potential witness when the potential witness has an explicit
"@nonobjc" attribute on it. Otherwise, the presence of @objc and the
corresponding Objective-C name is checked only after selecting a
candidate. This more closely mirrors what we do for override checking,
where we match based on the Swift names (first) and validate
@objc'ness afterward. It is also a stepping stone to inferring
@objc'ness and @objc names from protocol conformances.
Second, when emitting a diagnostic about a missing or incorrect @objc
annotation, make sure the Fix-It gets the @objc name right: this might
mean adding the Objective-C name along with @objc (e.g.,
"@objc(fooWithString:bar:)"), adding the name to an
unadorned-but-explicit "@objc" attribute, or fixing the name of an
@objc attribute (e.g., "@objc(foo:bar:)" becomes
@objc(fooWithString:bar:)"). Make this diagnostic an error, rather
than a note on a generic "does not conform" diagnostic, so it's much
easier to see the diagnostic and apply the Fix-It.
Third, when emitting the warning about a non-@objc near-match for an
optional @objc requirement, provide two Fix-Its: one that adds the
appropriate @objc annotation (per the paragraph above), and one that
adds @nonobjc to silence the warning.
Part of the QoI improvements for conformances to @objc protocols,
rdar://problem/25159872.
When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
Simplify and improve the checking of @objc names when matching a
witness to a requirement in the @objc protocol. First, don't use
@objc-ness as part of the initial screening to determine whether a
witness potentially matches an @objc requirement: we will only reject
a potential witness when the potential witness has an explicit
"@nonobjc" attribute on it. Otherwise, the presence of @objc and the
corresponding Objective-C name is checked only after selecting a
candidate. This more closely mirrors what we do for override checking,
where we match based on the Swift names (first) and validate
@objc'ness afterward. It is also a stepping stone to inferring
@objc'ness and @objc names from protocol conformances.
Second, when emitting a diagnostic about a missing or incorrect @objc
annotation, make sure the Fix-It gets the @objc name right: this might
mean adding the Objective-C name along with @objc (e.g.,
"@objc(fooWithString:bar:)"), adding the name to an
unadorned-but-explicit "@objc" attribute, or fixing the name of an
@objc attribute (e.g., "@objc(foo:bar:)" becomes
@objc(fooWithString:bar:)"). Make this diagnostic an error, rather
than a note on a generic "does not conform" diagnostic, so it's much
easier to see the diagnostic and apply the Fix-It.
Third, when emitting the warning about a non-@objc near-match for an
optional @objc requirement, provide two Fix-Its: one that adds the
appropriate @objc annotation (per the paragraph above), and one that
adds @nonobjc to silence the warning.
Part of the QoI improvements for conformances to @objc protocols,
rdar://problem/25159872.
wraps up SE-0004 and SE-0029.
I consider the diagnostic changes in Constraints/lvalues.swift to be
indicative of a QoI regression, but I'll deal with that separately.
Though the generic type information isn't present, it isn't necessary if we're just invoking other operations from Objective-C. This should allow an extension to use the generic class's own API to some degree, as it would if defined on the nongeneric form.
Type level lookups can fail because the lookup is on an existential
metatype, like `MyProtocol.staticMethod(_:)` is invalid; however the
error message is unclear: “static member 'staticMethod(_:)' cannot be
used on instance of type ‘MyProtocol.Protocol’”.
This fix checks the base of member lookups that failed with the reason
UR_TypeMemberOnInstance for being existential metatypes. It produces
the clearer message “static member ‘staticMethod(_:)’ cannot be used on
protocol metatype ‘MyProtocol.Protocol’”. This change makes it clear
that the use of a static member on the *existential* metatype is the
problem.
If a subclass grounds all the type parameters from its base class, we don't have to worry about any erasure edge cases. We should be able to support this, giving existing code that subclasses the nongeneric form of the class a migration path. Spot-fix some places in IRGen where we assume we can't emit static references to ObjC generic classes or metaclasses.
When a Clang-defined Objective-C class has the objc_runtime_visible
attribute, use objc_lookUpClass to get the Objective-C class object
rather than referencing the symbol directly. Also, ban subclassing of
Objective-C-runtime-visible classes as well as @objc on members of
extensions of such classes.
As a drive-by needed for this test, make
ClassDecl::getObjCRuntimeName() respect the Clang objc_runtime_name
attribute.
Fixes rdar://problem/25494454.
Fix an i32 vs. 64 issue in the IR matching for the IR generation test.
This reverts commit 09973e6956.
When a Clang-defined Objective-C class has the objc_runtime_visible
attribute, use objc_lookUpClass to get the Objective-C class object
rather than referencing the symbol directly. Also, ban subclassing of
Objective-C-runtime-visible classes as well as @objc on members of
extensions of such classes.
As a drive-by needed for this test, make
ClassDecl::getObjCRuntimeName() respect the Clang objc_runtime_name
attribute.
Fixes rdar://problem/25494454.
We can't reify the type parameters of an ObjC generic class for use within a Swift extension method, but we can allow methods that don't make use of the generic parameters.
When the selector named by Selector("foo") does not map to a known
Objective-C method, allow one to suppress the warning by wrapping the
string literal in an extra set of parentheses, e.g.,
Selector(("foo"))
Suggest this via a Fix-It on a note so it's discoverable. Addresses
rdar://problem/24791200.
This was mistakenly reverted in an attempt to fix buildbots.
Unfortunately it's now smashed into one commit.
---
Introduce @_specialize(<type list>) internal attribute.
This attribute can be attached to generic functions. The attribute's
arguments must be a list of concrete types to be substituted in the
function's generic signature. Any number of specializations may be
associated with a generic function.
This attribute provides a hint to the compiler. At -O, the compiler
will generate the specified specializations and emit calls to the
specialized code in the original generic function guarded by type
checks.
The current attribute is designed to be an internal tool for
performance experimentation. It does not affect the language or
API. This work may be extended in the future to add user-visible
attributes that do provide API guarantees and/or direct dispatch to
specialized code.
This attribute works on any generic function: a freestanding function
with generic type parameters, a nongeneric method declared in a
generic class, a generic method in a nongeneric class or a generic
method in a generic class. A function's generic signature is a
concatenation of the generic context and the function's own generic
type parameters.
e.g.
struct S<T> {
var x: T
@_specialize(Int, Float)
mutating func exchangeSecond<U>(u: U, _ t: T) -> (U, T) {
x = t
return (u, x)
}
}
// Substitutes: <T, U> with <Int, Float> producing:
// S<Int>::exchangeSecond<Float>(u: Float, t: Int) -> (Float, Int)
---
[SILOptimizer] Introduce an eager-specializer pass.
This pass finds generic functions with @_specialized attributes and
generates specialized code for the attribute's concrete types. It
inserts type checks and guarded dispatch at the beginning of the
generic function for each specialization. Since we don't currently
expose this attribute as API and don't specialize vtables and witness
tables yet, the only way to reach the specialized code is by calling
the generic function which performs the guarded dispatch.
In the future, we can build on this work in several ways:
- cross module dispatch directly to specialized code
- dynamic dispatch directly to specialized code
- automated specialization based on less specific hints
- partial specialization
- and so on...
I reorganized and refactored the optimizer's generic utilities to
support direct function specialization as opposed to apply
specialization.
Temporarily reverting @_specialize because stdlib unit tests are
failing on an internal branch during deserialization.
This reverts commit e2c43cfe14, reversing
changes made to 9078011f93.
It is a common point of confusion that code like:
switch value {
case .Foo, .Bar where someNumber != 100:
Only applies the where clause to the second pattern, not every pattern in the case.
Resolve this by warning about the ambiguity, providing two notes (with fixits) that
resolve the issue in different ways:
t.swift:25:17: warning: 'where' only applies to the second pattern match in this case
case .Foo, .Bar where someNumber != 100:
~~~~ ^ ~~~~~~~~~~~~~~~~~
t.swift:25:12: note: disambiguate by adding a line break between them if this is desired
case .Foo, .Bar where someNumber != 100:
^
t.swift:25:6: note: duplicate the 'where' on both patterns to check both patterns
case .Foo, .Bar where someNumber != 100:
^~~~
where someNumber != 100
This attribute can be attached to generic functions. The attribute's
arguments must be a list of concrete types to be substituted in the
function's generic signature. Any number of specializations may be
associated with a generic function.
This attribute provides a hint to the compiler. At -O, the compiler
will generate the specified specializations and emit calls to the
specialized code in the original generic function guarded by type
checks.
The current attribute is designed to be an internal tool for
performance experimentation. It does not affect the language or
API. This work may be extended in the future to add user-visible
attributes that do provide API guarantees and/or direct dispatch to
specialized code.
This attribute works on any generic function: a freestanding function
with generic type parameters, a nongeneric method declared in a
generic class, a generic method in a nongeneric class or a generic
method in a generic class. A function's generic signature is a
concatenation of the generic context and the function's own generic
type parameters.
e.g.
struct S<T> {
var x: T
@_specialize(Int, Float)
mutating func exchangeSecond<U>(u: U, _ t: T) -> (U, T) {
x = t
return (u, x)
}
}
// Substitutes: <T, U> with <Int, Float> producing:
// S<Int>::exchangeSecond<Float>(u: Float, t: Int) -> (Float, Int)
With the exception of a specific whitelist of cases where the
Foundation module defines conformances to _ObjectiveCBridgeable for
standard library types, only permit an _ObjectiveCBridgeable
conformance in the same module as the type that's conforming to the
protocol. Among other things, this prevents the optimizer from
concluding that a dynamic cast between a Swift value type and its
bridged Objective-C class type can never succeed. See
34ff1c8e6d
for the optimizer issue. As part of this, bring the whitelist in sync
with reality, now that the compiler enforces it.
Split up parsing of typealias and associatedtype, including dropping a
now unneeded ParseDeclOptions flag.
Then made typealias in a protocol valid, and act like you would
hope for protocol conformance purposes (i.e. as an alias possibly
involved in the types of other func/var conformances, not as a hidden
generic param in itself).
Also added support for simple type aliases in generic constraints. Aliases
to simple (non-sugared) archetype types (and also - trivially - aliases to
concrete types) can now be part of same-type constraints.
The strategy here is to add type aliases to the tree of
PotentialArchetypes, and if they are an alias to an archetype, also to
immediately find the real associated type and set it as the
representative for the PA. Thus the typealias PA node becomes just a
shortcut farther down into the tree for purposes of lookup and
generating same type requirements.
Then the typealias PA nodes need to be explicitly skipped when walking
the tree for building archetype types and other types of requirements,
in order to keep from getting extra out-of-order archetypes/witness
markers of the real associated type inserted where the typealias is
defined.
Any constraint with a typealias more complex than pointing to a single
nested associated type (e.g. `typealias T = A.B.C.D`), will now get a
specialized diagnoses.
There's an immediate need for this in the core libs, and we have most of the necessary pieces on hand to make it easy to implement. This is an unpolished initial implementation, with the following limitations, among others:
- It doesn't support bridging error conventions,
- It relies on ObjC interop,
- It doesn't check for symbol name collisions,
- It has an underscored name with required symbol name `@cdecl("symbol_name")`, awaiting official bikeshed painting.
in arbitrary places. This fixes a regression caught by SR-770 that
would otherwise be introduced by us removing automatic currying syntax,
it allows the use of @noescape on typealiases (resolving SR-824),
allows @noescape on nested function types (fixing rdar://19997680)
and allows @noescape to be used on local variables (fixing
rdar://19997577).
At this point, @noescape should stop being a decl attribute, but I'll bring
that up on swift-evolution.
Try to match the original spelling of static/class in diagnostics and
when printing the AST. Also fixes cases with
PrintOptions.PrintImplicitAttrs = false, where we would just print
'class', which was not valid code.
Allow a behavior protocol to declare an `initStorage` implementation with a parameter. If we have an initializer expression, use `initStorage(initExpr)` to initialize the storage; otherwise, remember the storage declaration and its initializer. Definite
initialization will have to use these to insert the initialization operation for the behavior property at the right place.
Parser now accepts multiple patterns in switch cases that contain variables.
Every pattern must contain the same variable names, but can be in arbitrary
positions. New error for variable that doesn't exist in all patterns.
Sema now checks cases with multiple patterns that each occurence of a variable
name is bound to the same type. New error for unexpected types.
SILGen now shares basic blocks for switch cases that contain multiple
patterns. That BB takes incoming arguments from each applicable pattern match
emission with the specific var decls for the pattern that matched.
Added tests for all three of these, and some simple IDE completion
sanity tests.
If a behavior protocol requires an `initialValue` static property, satisfy the requirement using the initial value expression from the property declaration. This lets us implement `lazy` as a property behavior.
Parse 'var [behavior] x: T', and when we see it, try to instantiate the property's
implementation in terms of the given behavior. To start out, behaviors are modeled
as protocols. If the protocol follows this pattern:
```
protocol behavior {
associatedtype Value
}
extension behavior {
var value: Value { ... }
}
```
then the property is instantiated by forming a conformance to `behavior` where
`Self` is bound to the enclosing type and `Value` is bound to the property's
declared type, and invoking the accessors of the `value` implementation:
```
struct Foo {
var [behavior] foo: Int
}
/* behaves like */
extension Foo: private behavior {
@implements(behavior.Value)
private typealias `[behavior].Value` = Int
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
If the protocol requires a `storage` member, and provides an `initStorage` method
to provide an initial value to the storage:
```
protocol storageBehavior {
associatedtype Value
var storage: Something<Value> { ... }
}
extension storageBehavior {
var value: Value { ... }
static func initStorage() -> Something<Value> { ... }
}
```
then a stored property of the appropriate type is instantiated to witness the
requirement, using `initStorage` to initialize:
```
struct Foo {
var [storageBehavior] foo: Int
}
/* behaves like */
extension Foo: private storageBehavior {
@implements(storageBehavior.Value)
private typealias `[storageBehavior].Value` = Int
@implements(storageBehavior.storage)
private var `[storageBehavior].storage`: Something<Int> = initStorage()
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
In either case, the `value` and `storage` properties should support any combination
of get-only/settable and mutating/nonmutating modifiers. The instantiated property
follows the settability and mutating-ness of the `value` implementation. The
protocol can also impose requirements on the `Self` and `Value` types.
Bells and whistles such as initializer expressions, accessors,
out-of-line initialization, etc. are not implemented. Additionally, behaviors
that instantiate storage are currently only supported on instance properties.
This also hasn't been tested past sema yet; SIL and IRGen will likely expose
additional issues.
