We don't want to show the funny "getter:Foo.bar(self:)" syntax to
developers, so whenever possible be a little more explicit.
'foo' has been replaced by 'X.newFoo'
'bar(x:)' has been replaced by property 'X.bar'
'baz(x:y:)' has been replaced by instance method 'X.baz(y:)'
(We do run up against the limitation of a string -- this diagnostic
does not do any lookup to find out if the resulting decl actually exists.)
Example:
@available(*, unavailable, renamed: "setter:CGRect.diagonal(self:_:)")
func scale(_ rect: inout CGRect, toDiagonalLength length: CGFloat)
(My examples are getting more and more contrived, but there you go.)
This is pretty much the same as the getter handling, except that we also
want to strip off the '&' at the call site.
While I'm at it, prefer deleting trailing commas and space to leading
commas and space when removing an argument. That's a little more
aesthetically pleasing. We still have to delete a preceding comma if
it's the last argument that's being removed.
Example:
@available(*, unavailable, renamed: "getter:UIColor.CIColor(self:)")
func convertToCIColor(_ color: UIColor) -> CIColor
This syntax looks weird, but it's the same as what's used by
NS_SWIFT_NAME. I intend to improve the diagnostic text once I have
all the fix-its working.
Next up: setters!
Example:
@available(*, unavailable, renamed: "Sequence.enumerated(self:)")
func enumerate<Seq: SequenceType>(_ sequence: Seq) ->
EnumerateSequence<Seq>
This will allow us to reuse this logic to suggest fixes for APIs
turned into members by NS_SWIFT_NAME.
It's going to share some helper functions with
TypeChecker::diagnoseExplicitUnavailability, which is already there.
Also, avoid unnecessarily putting some lambdas on the heap by using
llvm::function_ref.
No functionality change.
The differences between Swift 2 and Swift 3 names can be very
significant, when the Swift 2 names have a lot of restated type
information. These differences end up disabling the near-miss
heuristics because the magnitude of the change is so high. Therefore,
apply the omit-needless-words heuristics to the potential witness and
the requirement before scoring them.
Should finish up rdar://problem/25159872 for real.
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.
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.
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.
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.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
- Fix SR-1112, where the fixit would eat all characters in the RHS expression except for the last one due to improper SourceRange math.
- Noticed by inspection, an expression undergoing an implicit conversion (such as a load from an optional `var`) would be judged as requiring parens, when that's really unnecessary.
The AvailabilityWalker was creating a new AvailabilityWalker instance whenever it
recursed through an assignexpr or memberrefexpr, which produced a new ExprStack.
This caused the fixit mechanics for migrating ++/-- to think that the ++/-- was
at the top level, when it wasn't.
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.
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
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.
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.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
UnresolvedConstructorExpr is not providing any value here; it's
essentially just UnresolvedDotExpr where the name refers to an
initializer, so use that instead. NFC
When member lookup completely fails and when CSDiags is the one performing
the lookup, reissue another lookup that ignores access control. This allows
it to find inaccessible members and diagnose them as such, instead of pretending
we have no idea what the user wants. We now produce an error message like this:
main.swift:1:6: error: 'foo' is inaccessible due to 'private' protection level
C().foo()
^
test.swift:1:35: note: 'foo' declared here
internal class C { private func foo() {} }
^
instead of:
main.swift:1:2: error: value of type 'C' has no member 'foo'
C().foo()
^~~ ~~~
This adds a Sema check that super methods aren't partially applied,
since we are removing currying declaration syntax. Once that lands,
this can be reverted and the test removed.
Under -enable-infer-default-arguments, the Clang importer infers some
default arguments for imported declarations. Rather than jumping
through awful hoops to make sure that we create default argument
generators (which will likely imply eager type checking), simply
handle these cases as callee-side expansions.
This makes -enable-infer-default-arguments usable, fixing
rdar://problem/24049927.
instead of types, with a bugfix. We make sure to check for
DefaultArgumentKind::None instead of checking for the presence of a
default value. These are different when dealing with deserialized
models and clang importer results.
