When we see a string literal used to initializer a Selector, and that
string literal names the selector for the getter or setter of an
Objective-C property, suggest #selector(getter: ...) or
This completes SE-0064. Big thanks for Alex Hoppen (@ahoppen) for his
contributions here.
This was easy with a bit of refactoring, but eventually I'd love to
converge override checking and witness checking logic a bit more.
Fixes <rdar://26183366>.
Implements the core functionality of SE-0064 / SR-1239, which
introduces support for accessing the Objective-C selectors of the
getter and setter of an @objc property via #selector(getter:
propertyName) and #selector(setter: propertyName).
Introduce a bunch of QoI around mistakes using #selector to refer to a
property without the "getter:" or "setter:", using Fix-Its to help the
user get it right. There is more to do in this area, still, but we
have an end-to-end feature working.
Much of the implementation and nearly all of the test cases are from
Alex Hoppen (@ahoppen). I've done a bit of refactoring, simplified the
AST representation, and replaced Alex's custom
expression-to-declaration logic with an extension to the constraint
solver. The last bit might be short-lived, based on swift-evolution
PR280, which narrows the syntax of #selector considerably.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
This reverts commit 073f427942,
i.e. it reapplies 35ba809fd0 with a
test fix to expect an extra note in one place.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
This is a /slightly/ more user-friendly option than
-debug-time-function-bodies; pass it a limit in milliseconds and
the compiler will warn whenever a function or multi-statement closure
takes longer than that to type-check.
Since it's a frontend option (and thus usually passed with -Xfrontend),
I went with the "joined" syntax as the common case. The usual "separate"
syntax of "-warn-long-function-bodies <N>" is also available.
As a frontend option, this is UNSUPPORTED and may be removed without
notice at any future date.
Additional caveats:
- Other parts of type-checking not measured by this may also be slow.
- May include first-use penalties (i.e. "this is slow because it's
the first function that references an imported type, which causes
many things to be imported")
- Does not report anything whatsoever about other phases of compilation
(SILGen, optimization, IRGen, assembly emission, whatever).
- Does not catch anything accidentally being type-checked multiple times
(a known issue for initial value expressions on properties).
This at least emits notes when someone overrides something but
gets the types a little wrong (more than just mismatched optionals,
as handled in d669d152).
Part of rdar://problem/26183575
Sema was dutifully tracking conformances that were "used" as part of
type checking, so it could make sure that those conformances got
completed for SILGen to use. However, this information never actually
made it to SILGen, which included its own (more conservative, not
broad enough) heuristics for finding "used" conformances. Teach Sema
to record conformances within the appropriate source file, and have
SILGen reference the conformances when it emits SIL for the source
file.
This is the second half of the previous commit. The most common case
of this will be due to the new rules for imported Objective-C API,
but it will also catch things like "I forgot to make the first
parameter not have an argument label".
When attempting to compile Swift 2 code (or any Swift code using the
Swift 2 names) in Swift 3, the compiler diagnostics are often entirely
useless because the names have changed radically enough that one
generally gets "no member named 'foo'" errors rather than a helpful
"'foo' was renamed to 'bar'" error. This makes for a very poor user
experience when (e.g.) trying to move Swift 2 code forward to Swift 3.
To improve the experience, when the Swift 2 and Swift 3 names of an
API differ, the Clang importer will produce a "stub" declaration that
matches the Swift 2 API. That stub will be marked with a synthesized
attribute
@available(unavailable, renamed: "the-swift-3-name")
that enables better diagnostics (e.g., "'foo' is unavailable: renamed
to 'bar') along with Fix-Its (courtesy of @jrose-apple's recent work)
that fix the Swift 2 code to compile in Swift 3.
This change addresses much of rdar://problem/25309323 (concerning QoI
of Swift 2 code compiled with a Swift 3 compiler), but some cleanup
remains.
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.
This is a squash of the following commits:
* [SE-0054] Import function pointer arg, return types, typedefs as optional
IUOs are only allowed on function decl arguments and return types, so
don't import typedefs or function pointer args or return types as IUO.
* [SE-0054] Only allow IUOs in function arg and result type.
When validating a TypeRepr, raise a diagnostic if an IUO is found
anywhere other thn the top level or as a function parameter or return
tpye.
* [SE-0054] Disable inference of IUOs by default
When considering a constraint of the form '$T1 is convertible to T!',
generate potential bindings 'T' and 'T?' for $T1, but not 'T!'. This
prevents variables without explicit type information from ending up with
IUO type. It also prevents implicit instantiation of functions and types
with IUO type arguments.
* [SE-0054] Remove the -disable-infer-iuos flag.
* Add nonnull annotations to ObjectiveCTests.h in benchmark suite.
When a particular method/initializer/property/subscript is used to
satisfied a requirement in an @objc protocol, infer both the presence
of @objc and the @objc name so that it matches the requirement. This
eliminates the need to explicitly specify @objc and @objc(foo:bar:) in
most cases. Note that we already did this for overrides, so it's a
generalization of that behavior.
Note that we keep this inference somewhat local, checking only those
protocols that the enclosing context conforms to, to limit
spooky-action-at-a-distance inference. It's possible that we could
lift this restriction later.
Fixes rdar://problem/24049773.
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.
Without this fix, we would accidentally consider the autoclosure to capture the capture list decl, even though it's natively within the autoclosure's context. Fixes SR-848.
* 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.
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.
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.
