What’s there to say about a week like this? Might as well just talk about Swift.

In this brief, we discuss the 2016 LLVM Developers’ Meeting, “eager” bridging, and link to detailed instructions on how Swift contributors are testing for compile time performance.

Starter tasks

Many new Swift contributors choose to work on the Swift standard library. Last week Swift Weekly linked to Ole Begemann’s post on How to Read the Swift Standard Library Source. Another great resource is Russ Bishop’s talk, Contributing to Swift: From Proposal to Shipped.

This week’s starter tasks, on the other hand, focus on the Swift compiler itself. Yes, it’s written in C++, and yes, working on a compiler can be daunting. But these tasks are small, tangible improvements, many of which can be done even by someone who’s never written C++ before.

• SR-3164: The goal of this task is to rename .swiftdeps files to prevent them from being overwritten after an incremental compilation. If you know some C++, you can help make incremental compilation failures easier to diagnose! This code lives in the Swift driver, which is a great starting point, especially if you’re only just starting to learn about compilers.
• SR-3167: If you name a function func switch(), you get an error: expected identifier in function declaration. The problem is that switch is a reserved keyword in Swift – but you’d never guess that from that error message! This task is to improve the error message.
• SR-3168: The goal of this task is to provide a fix-it for the 'optional' can only be applied to protocol members error message. Implementing it would probably take only a few short lines of C++, and you could really help someone out!

Thanks to Jordan Rose for creating so many great starter tasks!

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

News and community

The 2016 Bay Area LLVM Developers’ Meeting was held on November 3rd and 4th. The event focuses on LLVM and Clang, and while none of the speakers referenced Swift specifically, many members of the Swift core team were in attendance. Expect slides from the talks to be released within a week or two. Video recordings will eventually be available as well.

At the meeting, discussions on moving LLVM from SVN onto Git and GitHub continued. Although it was decided that LLVM would move to GitHub, a major roadblock remains: reaching a consensus on whether to have LLVM, Clang, and the various other projects remain in separate repositories as they do today (a “multirepo” approach), or whether all the repositories should be placed in a single repository (a “monorepo”).

If you’re waiting for LLVM to move to GitHub before you start contributing, don’t hold your breath. In the meantime, LLVM’s Getting Started and Code Reviews with Phabricator guides explain how to send patches to LLVM projects.

Chris Bieneman presented on how migrating Clang’s build system from autoconf to CMake has benefited that project. Although the talk did not mention Swift’s build system, it’s clear that LLVM and Clang’s usage of CMake is very different from Swift’s.

Commits and pull requests

Alexis Beingessner sent pull requests for eager array and string bridging. Currently, Objective-C’s NSArray and NSString are bridged into Swift by keeping a reference to a -copy of the Objective-C object, then forwarding messages to and from it. This has a performance overhead that can be eliminated by “eagerly” copying the contents of the NSArray or NSString into a Swift Array or String once, at the time that the Objective-C object is first bridged to Swift. Doug Gregor explains eager bridging here.

Slava Pestov sent a pull request that enables nested types within generic types. This resolves an ABI FIXME in the Swift standard library.

Alex Hoppen sent a pull request to fix a regression reported by Erica Sadun, in which annotating generic parameters to closures arguments as inout doesn’t quite work. This is an excellent example of a improvement to compiler internals that was both reported and addressed by non-Apple contributors to Swift.

Simon Evans sent a pull request that would allow the Swift package manager to create static libraries on Linux.

David Aghassi sent a pull request to add documentation to SourceKit’s complete.open request type. SourceKit is largely undocumented, and could use your help! See SR-2117 for details.

Xi Ge added a new SourceKit request type, range, which provides information about a selected snippet of code.

Dave Abrahams sent a pull request to improve the Emacs support files included in the Swift repository.

Hugh Bellamy sent instructions on how to compile and run Swift on Windows, via Bash on Windows.

Proposals in review

Doug Gregor’s SE-0143, Conditional conformances, is back in review.

During the first round of review for SE-0143, there was concern about the clarity of the proposal as written, since the discussion fixated on a number of ancillary issues not intended to be core to the proposal. Doug has revised the proposal for another round of feedback, so the review period for this proposal has been extended through November 15.

Mailing lists

Graydon Hoare posted advice on how Swift contributors can test for compile time performance. His attachment was scrubbed from the mailing list archives, but you can read it here.

Brian Gesiak posted results from running the PVS-Studio static analyzer on the Swift codebase. Based on the analyer warnings, Michael Ilseman removed some unused method arguments.

Finally

Look on my works, ye abstractions, and despair!