change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
Introduce bridging of NSError to ErrorProtocol, so an Objective-C API
expressed via an "NSError *" will be imported using ErrorProtocol in
the Swift. For example, the Objective-C method:
- (void)handleError:(NSError *)error userInteractionPermitted:(BOOL)userInteractionPermitted;
will now be imported as:
func handleError(_ error: ErrorProtocol, userInteractionPermitted: Bool)
This is bullet (3) under the proposed solution of SE-0112. Note that
we made one semantic change here: instead of removing the conformance
of NSError to ErrorProtocol, which caused numerous problems both
theoretical and actual because the model expects that an NSError
conforms to ErrorProtocol without requiring wrapping, we instead limit
the ErrorProtocol -> NSError conversion that would be implied by
bridging. This is defensible in the short term because it also
eliminates the implicit conversion, and aligns with SE-0072, which
eliminates implicit bridging conversions altogether.
This adds a narrow special case in code-completion for control-flow-like
methods such as DispatchQueue().sync that are () -> (), to add a new
completion where the trailing closure is immediately expanded rather
than having to invoke placeholder expansion as a second step.
rdar://problem/26628804
Rather than using a specialized matching rule in the type checker that
depends on having default arguments in types, use call argument
matching consistently.
Note #1: This (correctly) breaks some existing code that depends on
inferring a parameter type of () for a single-argument parameter from
a no-argument function type().
Note #2: This pessimizes a code completion test, where the code
completion engine seems to depend on some quirks of argument
matching. The "type relationship" matching needs non-trivial work.
This flag tracks whether we have a special kind of imported class
that has limitations in what you can do with it. Currently it's
used for two things: CF classes, and the magic "Protocol" class used
to represent Objective-C protocol metadata. I'm planning to add a
third to handle classes with the recently-added objc_runtime_visible
attribute, which describes an Objective-C class whose runtime symbols
are hidden (forcibly preventing categories and subclassing). This is
used for some of the types in Dispatch, which has exposed some of the
classes that were considered implementation details on past OSs.
I'm splitting the flag into an enum rather than just marking the
Dispatch classes with the existing flag because we still need to
be able to /cast/ to the Dispatch types (which you can't do with CF
types today) and because they deserve better than to be lumped in
with CF for diagnostic purposes.
Groundwork for rdar://problem/26850367, which is that Swift will
happily let you extend the new Dispatch classes but then fails to find
the symbols at link-time.
Rather than relying on the embedding of default argument information
into tuple types (which is gross), make sure that the various clients
(type checker, type checker diagnostics, constraint application) can
dig out the callee declaration and retrieve that information from
there.
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr.
This is a slightly-pared-back version of
3753d779bc that isn't so rigid in its
interpretation of ASTs. I'll tighten up the semantics over time.
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr. We were also
allowing weird ASTs to effectively disable this information: tighten
that up and require that CallExprs always have a ParenExpr, TupleExpr,
or (as a temporary hack) a TypeExpr whose representation is a
TupleTypeRepr as their argument prior to type checking. This gives us
a more sane AST to work with, and guarantees that we aren't losing
label information.
From the user perspective, this should be NFC, because it's mostly AST
cleanup and staging.
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.
With a TypeLoc, we have a chance to offer diagnostics or even fix-its
to the contextual type, even though it's not represented by an
expression in the constraint system. This commit mostly just passes it
through, without attempting to use it anywhere or even pass a real
TypeLoc (with a valid TypeRepr).
(It does drop the contextual type parameter from
typeCheckExpressionShallow, since there were zero callers using it.)
No functionality change...yet.
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.
immediately discard as non-viable any declarations that cannot be
called due to argument-label mismatch.
This heuristic already existed, but it was badly out-of-date vs.
the current language rules on argument-passing. Change it to use
the standard argument matching algorithm.
This greatly reduces the number of overloads we consider for certain
kinds of expression, most importantly explicit initialization syntax
('T(x)'). Ordinary type-matching will quickly reject such calls,
but backtracking will discard this rejection. Thus this heuristic
can greatly decrease the total work done by the type-checker when
something else in the system is causing a combinatorial explosion.
The diagnostic changes in the test-suite seem acceptable to me.
Shout-out to Doug for pointing out multiple places where I didn't
need to reinvent the wheel.
In member ref expressions, if the base is optional, and the expected
expression result is either optional or unknown, suggest a fixit that
makes it into an optional chain expr rather than force unwrapping.
Since in many cases the actual fixit is emitted during diagnosis, and
thus, while type checking sub exprs with no contextual type specified
(so nothing to check for preferring optionality), we also need an
additional flag to pass down from FailureDiagnosis for whether we
prefer to fix as force unwrapping or optional chaining.
I attempted to do this same job via providing a convert type but
setting the ConvertTypeIsOnlyAHint flag on the type checker, but
unfortunately there are a lot of other moving parts that look at that
type, even if it is only supposed to be a hint, so an additional flag
to the CS ended up being cleaner.
Passing a function type to an @autoclosure param would always fail to
type check because of the attempt to decompose the parallel structure
of the two (both being functions). In this case, though, we don’t want
to do any such thing, we want to allow the ExprRewriter to explicitly
insert an AutoClosureExpr in coerceToType, as it would do with any
other non-function arg type.
We had four duplicated implementations of checking how a protocol
requirement uses 'Self', all slightly wrong or incomplete:
- When deciding if the protocol type can be used as an existential.
This one would just ignore 'Self' in the return type of a method
completely, which was incorrect for cases where 'Self' is
contravariant but part of the return value, for example:
func foo() -> (Self -> ())
- When deciding if a member access can be performed on an existential
value. This is distinct from the former, because the member may
have been defined in a protocol extension, in which case it cannot
be used even if the protocol type can be used as an existential.
Unfortunately, this implementation was overly conservative, and
would reject uses of 'Self' where Sema could in fact erase the
existential type, for example:
func foo() -> Self??
func foo() -> Self.Type
func foo() -> (Self, Self)
This function handled function return types correctly, effectively
plugging the leak in the previous code. It did lead to inconsistent
behavior with protocols that had contravariant Self in requirements
though; sometimes we would diagnose uses of the existential type,
other times we would only complain about specific members.
- When deciding if a method in a non-final class can model a protocol
requirement. This one was the most elaborate one, but here
contravariance and uses of associated types are actually okay, so
it was written to pick up covariant 'Self' only. However, it also
did not handle metatypes and tuples.
- When opening the type of member of an existential, we would check
if the return value was 'Self' or an optional of 'Self', but again
this check was too conservative, so after the previous three were
fixed, we could reference members on existentials that did not
have a correct opened type.
Now, these have been combined into one check. To fix some crashes,
Sema's implementation of erasing existentials now relies on
coerceToType() instead of hand-rolling a few coercions of its own,
and wrapping the rest in CovariantFunctionConversionExpr, which
didn't make much sense if the result was not a function type.
SILGen still does not support function type conversions where an
existential return value is being erased; these would silently
miscompile before, but crash with an assertion now, because they
are correctly modeled as a FunctionConversionExpr, and not
CovariantFunctionConversionExpr.
The issue here is that the constraint solver was deciding on
FixKind::RelabelCallTuple as the fix for the problem and emitting the
diagnostic, even though there were two different fixes possible.
CSDiags has the infrastructure to support doing doing the right thing
here, but is only being used for ApplyExprs, not SubscriptExprs.
The solution is to fix both problems: remove FixKind::RelabelCallTuple,
to let CSDiags handle the problem, and enhance CSDiags to treat
SubscriptExpr more commonly with ApplyExpr. This improves several cases
where the solver was picking one solution randomly and suggesting that
as a fix, instead of listing that there are multiple different solutions.
Not all types are l-valuable, notably InoutType's. This seems like a
weird restriction to put in the type checker, but it is the cleanest
solution to this. The better solution would be to change how
inoutexpr/inouttype are represented completely... maybe someday.
tested in the testsuite because they are generally already handled
by the CSDiags infrastructure. Remove them in prep for dismantling
the Failure infrastructure. NFC.
