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.
As implied in rdar://24818863, striking through a module name may be an overkill to suggest the module is redundant to import. We try to
fine-grain not-recommended-reason so that proper UI cue can be adopted in the future.
We have code for pruning unlikely overloads, but when it pruned all
overloads it was treating that as if there was nothing to complete.
Instead, fallback to postfix-expr-begin.
We should also figure out why we're not getting any viable types here,
but we need to handle failure gracefully.
rdar://problem/24356118
We don't actually want to skip non-type contexts here, since we should
only be showing override completions in the type context itself. This
was pretty obscure to hit in practice, but I noticed it while fixing the
crasher.
We generally don't want to override unavailable methods. We already
filter out unavailable decls when completing values, but that's in a
separate visible decl consumer.
rdar://problem/25058233
Except for nil literals, we don't want to look at the optional itself,
since the typechecker would implicitly look to the underlying type.
rdar://problem/24707210
We don't want to prioritize the type name for protocols, since they
can't be used (generally) to construct an instance of the type. Ideally
we would prioritize types that conform to the protocol.
For rdar://problem/24873625
When the LHS is an lvalue/assignable tuple and there is no leading
sequence of binary expressions.
It's a bit hacky right now since we don't have a good way to
differentiate general pattern completions from builtin operators.
rdar://problem/23209683
If there is a type context, hide literal suggesetions that don't match
it, unless they are keywords and we have filtered to their names.
Incidentally fix an output buffering issue when combining filtering with
the -raw flag in complete-test.
Part of rdar://problem/23865118
