Update for SE-0055: Making pointer nullability explicit. #304
Conversation
| encodeValueOfObjCType("[\(count)\(String(cString: type))]", at: array) | ||
| public func encodeArrayOfObjCType(type: UnsafePointer<Int8>, count: Int, at array: UnsafePointer<Void>?) { | ||
| // FIXME: What about empty arrays at null addresses? | ||
| encodeValueOfObjCType("[\(count)\(String(cString: type))]", at: array!) |
There was a problem hiding this comment.
I wasn't sure what to do in this case; this method can be called from encodeBytes(_:length:) with a null array. Maybe they should both have a separate helper function?
jrose-apple
force-pushed
the
optional-pointers
branch
from
601d840 to
45dbbb7
Compare
| @@ -73,11 +73,11 @@ struct _NSDictionaryBridge { | |||
| CFIndex (*countForKey)(CFTypeRef dictionary, CFTypeRef key); | |||
| bool (*containsKey)(CFTypeRef dictionary, CFTypeRef key); | |||
| _Nullable CFTypeRef (*_Nonnull objectForKey)(CFTypeRef dictionary, CFTypeRef key); | |||
| bool (*_getValueIfPresent)(CFTypeRef dictionary, CFTypeRef key, CFTypeRef _Nonnull * _Nullable value); | |||
| bool (*_getValueIfPresent)(CFTypeRef dictionary, CFTypeRef key, CFTypeRef _Nullable *_Nonnull value); | |||
There was a problem hiding this comment.
from a pedantic standpoint iirc this is doubly nullable
There was a problem hiding this comment.
Ah, are you permitted to use this to ask if a value is present? Okay, will change. Good catch!
|
This does not seem to build at all for me from the Xcode project, there are some errors in the interface for NSXMLParser. We need to have this compile for both darwin and linux |
|
Oooops. Will get on the Darwin side today. |
jrose-apple
force-pushed
the
optional-pointers
branch
from
45dbbb7 to
85761a3
Compare
|
Fixed the Darwin side. Now doing a second pass to (a) keep the public API in sync with the SDK shipped with Xcode 7.3, and (b) make sure no behavior changes snuck in. Also planning to rebase after the update for the new parameter naming rules. |
jrose-apple
force-pushed
the
optional-pointers
branch
3 times, most recently
from
10f1625 to
2099831
Compare
|
I'm sorry, this is as small as the patch is going to get. This is the minimal nice patch to get swift-corelibs-foundation to build (on both Linux and Darwin) under the compiler branch above. What I mean by a "nice" patch is preferring There are three actual behavior changes here:
All public APIs involving pointers ought to match their Darwin equivalents now, except for those in the following classes:
There's also an idiom of replacing calls passing |
|
@swift-ci please test |
|
Unfortunately that won't work; this depends on the branch in swiftlang/swift#1878. |
|
Ok, I think we decided to hold off on this for the time being then. |
jrose-apple
force-pushed
the
optional-pointers
branch
from
2099831 to
a27714b
Compare
[xctest] disable the test due to swiftlang/swift-corelibs-foundation#304
Revert "[xctest] disable the test due to swiftlang/swift-corelibs-foundation#304"
|
We're merging this to unblock the compiler work on this feature. We may have to iterate in master if it causes unintended fallout. @jroose-apple will coordinate. |
|
I reverted for now so that we can get all related PRs in at roughly the same time. |
Adopt swift-argument-parser for argument parsing
[pull] swiftwasm from main
See swiftlang/swift#1878. Note: this needs a coordinated merge, i.e. it must go in ASAP after that request!
@phausler or someone else, would you mind reviewing? I tried to keep APIs matching the nullability audit of the Darwin Foundation, and attempted to change as little behavior as possible besides that, but there were definitely a few rough spots.