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!

Starter tasks

  • SR-3359: [Compiler] Warn if @discardableResult is used with a Void result.
  • 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

Submit a task by sending a pull request or opening an issue.

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. 😎

ANTLR, ANother Tool for Language Recognition, now supports Swift. You can get started here. 🤓

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) implemented colorized output for -dump-parse and -dump-ast.

Slava Pestov (@slava_pestov) implemented evolution proposal SE-0110: Distinguish between single-tuple and multiple-argument function types. This is the first implemented proposal for Swift 4. 🎉

@antonmes submitted a pull request to corelibs-foundation to implement Thread.main and Thread.isMainThread.

Brian Gesiak (@modocache) sent a pull request that marks functions that can return twice, such as vfork and setjmp, unavailable in Swift. Swift code that used those functions would almost certainly crash.

Doug Gregor (@dgregor79) merged changes to the type checker to clean up as, as!, as?, and is casting. This refactoring resolves a number of SR bugs and radars.

Kevin Ballard (@eridius) merged changes to include unavailable/deprecated/availability attributes when printing Objective-C declarations for Swift functions.

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.

Roman Levenstein (@swiftix) sent a pull request with an initial implementation of the @_specialize attribute supporting layout constraints and partial specializations.


No updates this week! See the status page here.

Mailing lists

Michael Gottesman (@gottesmang) sent an email announcing a new tool called bug-reducer, inspired by LLVM’s bugpoint tool.

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:

  1. Given a crashing sil-opt invocation, reduce the number of functions in the input file to a minimal set causing a crash.
  2. 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.
  3. 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: ./swift/utils/bug-reducer/README.md.

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 Result types:

I’m personally a big fan of typed throws, but I know that John McCall has strong concerns. I can’t argue that typed throws is a high priority at the moment, but as soon as we start talking about concurrency the topic of a Result type 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 @objc inference:

Here’s a draft proposal to limit inference of @objc to 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 @objc on any Swift declaration that can be expressed in Objective-C. As a convenience, Swift also infers @objc in a number of places to improve interoperability with Objective-C and eliminate boilerplate. This proposal scales back the inference of @objc to only those cases where the declaration must be available to Objective-C to maintain semantic coherence of the model, e.g., when overriding an @objc method or implementing a requirement of an @objcprotocol.



And finally — If fixing bugs is called “debugging” … 😄