* Implement the majority of parsing support for SE-0039.
* Parse old object literals names using new syntax and provide FixIt.
For example, parse "#Image(imageLiteral:...)" and provide a FixIt to
change it to "#imageLiteral(resourceName:...)". Now we see something like:
test.swift:4:9: error: '#Image' has been renamed to '#imageLiteral
var y = #Image(imageLiteral: "image.jpg")
^~~~~~ ~~~~~~~~~~~~
#imageLiteral resourceName
Handling the old syntax, and providing a FixIt for that, will be handled in a separate
commit.
Needs tests. Will be provided in later commit once full parsing support is done.
* Add back pieces of syntax map for object literals.
* Add parsing support for old object literal syntax.
... and provide fixits to new syntax.
Full tests to come in later commit.
* Improve parsing of invalid object literals with old syntax.
* Do not include bracket in code completion results.
* Remove defunct code in SyntaxModel.
* Add tests for migration fixits.
* Add literals to code completion overload tests.
@akyrtzi told me this should be fine.
* Clean up response tests not to include full paths.
* Further adjust offsets.
* Mark initializer for _ColorLiteralConvertible in UIKit as @nonobjc.
* Put attribute in the correct place.
These types are not directly referenced as fields of aggregate types,
but are needed for reflection type lowering.
Also, use a SetVector to collect referenced builtin types, instead of
a SmallPtrSet, to ensure compiler output is deterministic.
Previously it was not possible to parse expressions of the form
[Int -> Int]()
because no Expr could represent the '->' token and be converted later
into a FunctionTypeRepr. This commit introduces ArrowExpr which exists
solely to be converted to FunctionTypeRepr later by simplifyTypeExpr.
https://bugs.swift.org/browse/SR-502
Use the diagnostics machinery of the protocol conformance checker to
say why each near-miss actually missed, e.g., a type conflict. This
gives better information regarding how to fix the actual problem. Yet
more QoI for rdar://problem/25159872.
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.
as well as on parameter decls. Also, tighten up the type checker to look at
parameter types instead of decl attributes in some cases (exposing a type
checker bug).
Still TODO:
- Reject autoclosure/noescape on non-parameter types.
- Move stdlib and other code to use noescape and autoclosure in the right
spot.
- Warn about autoclosure/noescape on parameters decls, with a fixit to move it.
- Upgrade the warning to an error.
- Extract the cache entry type to a top-level type that can be used in the
signature of the function.
- Rewrite the implementation of the type in terms of standard LLVM ADTs
instead of manual bit manipulation.
- Add support for trivial-with-optional types (none of which exist yet).
- Drop the use of SIL/BridgedTypes.def; the only non-trivial non-object
bridged type today is 'Bool' (for ObjCBool and DarwinBoolean) and that's
already trivially bridged to CBool too.
- Save an Identifier lookup when possible.
- Finally, rename the function to getForeignRepresentationInfo.
No intended functionality change.
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.
Under parameter doc comment list items, allow function doc comment
syntax to nest so you can document the meaning of closure parameters'
signatures.
rdar://problem/24794725
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.
It's possible for swift_name to make a global declaration into a
member of another entity that has not been seen yet. In such cases,
delay resolution until the end of the translation unit (module). Fixes
the rest of rdar://problem/25502497.
