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.
The test was supposed to use a CF type, but it wasn't updated
for the switch from a naming convention to an attribute. This
restores the original intent (and unfortunately slides all the
offsets).
This reverts commit f723b86614 and
updates the IDE tests that incidentally included some punctuation.
No new tests are necessary - the character level tests are exercised
in cmark itself.
These results are cached, so we can't use the type-relation. Instead we
use a small hack of checking the textual return type for "Void". This
is obviously not ideal, but it lets us detect the most important cases.
rdar://problem/22810741
Instead of using 'key.usr' and 'key.synthesizedusr', we start to use 'key.usr' and 'key.original-usr' so
that 'key.usr' is consistently being the unique ID for a code entity.
Unless you're familiar with the way the swift source code is organized,
it's not clear what "SourceDocInfo" means, or how it is different from
DocSupport, etc. Move the tests into directories that are named based
on their request (note: we already had one test under CursorInfo, which
just made things even more confusing).
experimental code-completion path. Move them right before "other module"
results. This is a bit of a hack. Ideally, we would have a much better
idea which keywords are actually legal/likely in a given context and
could prioritize them even more. Since today we basically splat in all
the keywords, keep them below the current module results so they don't
overwhelm us.
rdar://problem/25119529
We may know syntactically that we have an operator without being able to
find the associated operator decl when the input is invalid/incomplete.
Don't crash when that happens, and just fallback to a "free function"
decl kind.
rdar://problem/25196625
... in the experimental code-completion path. They seem to be generally
useful as a baseline result still as long as they are guaranteed to be
the first result.
rdar://problem/25177968
