Issue #51 05 Jan 2017
Written by: Jesse Squires
Welcome back to the weekly! Hopefully you enjoyed some time off over the last few weeks. As expected, the Swift project repos are back to buzzing with their usual activity. Welcome to 2017, let’s dive in!
- SR-3359: [Compiler] Warn if
@discardableResultis used with a
- SR-3281: [Compiler] The Swift man page is out of date
- SR-3207: [Compiler] Segmentation fault with Objective-C parameter of
NSError* __autoreleasing __nonnull * __nullable
News and community
Apple’s holiday period ended on January 3rd. The
master branch lock was released, CI buildbots returned online, and Apple employees merged over 30 pull requests that had piled up over the break.
Ray Fix (@rayfix) wrote an article, Unsafe Swift: Using Pointers And Interacting With C, which dives into the
Unsafe[Mutable][Raw][Buffer][Pointer][<T>] APIs in the standard library. Ray explains nearly everything you need to know about these APIs and how to use them. 😎
Chris Lattner shared his slides from his talk at IBM’s Programming Languages Day. In the talk, he discusses a number of things: potential improvements for Swift compiler, such as parallel WMO based on LLVM’s ThinLTO approach, Swift 5 is planned for release in 2018 and may include a concurrency model, and discussions on that concurrency model will begin in Spring/Summer 2017. 😱
Commits and pull requests
During the holiday break while the
master branch was locked, the team took some time to smash bugs. Slava Pestov opened a pull request with fixes for a number of compiler crashers. @practicalswift regularly posted status updates:
Currently there are 82 crashers marked as unresolved in the repo. Of those 82 crashers …
65 crashers have been fixed in submitted PRs which will be merged once master is unlocked (great work by this team: 34 crashers fixed by @xedin, 25 crashers fixed by @slavapestov and 6 crashers fixed by @CodaFi)
Brian Gesiak (@modocache) sent a pull request that marks functions that can return twice, such as
setjmp, unavailable in Swift. Swift code that used those functions would almost certainly crash.
Brian Gesiak (@modocache) opened a pull request that adds support for importing “function-like” macros from C and Objective-C. For now, only function-like macros that take no arguments, such as
#define MyMacro() 1, are imported.
No updates this week! See the status page here.
The tool called ‘bug-reducer’ is not a full bugpoint tool, but has what I believe to be the minimum functionality needed to be useful, namely:
- Given a crashing sil-opt invocation, reduce the number of functions in the input file to a minimal set causing a crash.
- Given a crashing sil-opt invocation, reduce the number of optimization passes run on the input file to a minimal set and then try to reduce functions.
- A random pass pipeline generator that runs N rounds of a permuted performance optimization pipeline and tries to reduce the test cases using the above tools if a crash is found.
For guides on use, please see the README at:
Consider this an early holiday gift from me to the Swift team. I hope it is useful. = ).
In a thread on moving the placement of and adding types to
throws, Chris Lattner commented on the possibility of
I’m personally a big fan of typed
throws, but I know that John McCall has strong concerns. I can’t argue that typed
throwsis a high priority at the moment, but as soon as we start talking about concurrency the topic of a
Resulttype will come back up (for use with futures/async).
I think that discussion will naturally drive the priority on settling the typed throws debate.
Doug Gregor sent a draft proposal on limiting
Here’s a draft proposal to limit inference of
@objcto only those places where we need it for consistency of the semantic model. It’s in the realm of things that isn’t needed for ABI stability, but if we’re going to make the source-breaking change here we’d much rather do it in the Swift 4 time-frame than later.
One can explicitly write
@objcon any Swift declaration that can be expressed in Objective-C. As a convenience, Swift also infers
@objcin a number of places to improve interoperability with Objective-C and eliminate boilerplate. This proposal scales back the inference of
@objcto only those cases where the declaration must be available to Objective-C to maintain semantic coherence of the model, e.g., when overriding an
@objcmethod or implementing a requirement of an
And finally — If fixing bugs is called “debugging” … 😄