[cfe-dev] Clang and Swift

[Douglas Gregor via cfe-dev]

Hi all,

As some of you may have heard, Swift has gone open-source over at swift.org <http://swift.org/>. Swift makes heavy use of Clang for its (Objective-)C interoperability, including loading Clang modules to map (Objective-)C APIs into Swift via Swift’s “Clang importer” and using Clang’s CodeGen to handle C ABI issues (record layout, calling conventions) and use C inline functions directly from Swift [*]. 

As an out-of-tree language front-end dependent on Clang, we have a clone of the llvm.org <http://llvm.org/> Clang repository over on GitHub at github.com/apple/swift-clang <http://github.com/apple/swift-clang>. We merge regularly and try to minimize our differences with llvm.org <http://llvm.org/>'s Clang—for more information on how we’re handling this, see swift.org/contributing/#llvm-and-swift <http://swift.org/contributing/#llvm-and-swift>.

That said, Swift’s clone of the Clang repository does have some content that isn’t in the llvm.org <http://llvm.org/> Clang repository. Here’s a quick summary of what that content is:

* There are several new attributes. We plan to propose these for inclusion into mainline Clang. They’re fairly small additions, some of which have wider applicability than Swift support:

	* ‘noescape’ attribute: indicates that the address provided by a particular function parameter of pointer/reference type won’t escape the function. At present, this is only used to map to Swift’s ‘noescape’ attribute, although we think it makes sense to use this for the LLVM IR “nocapture” parameter attribute as well.

	* ‘objc_subclassing_restricted’ attribute: indicates that a particular Objective-C class cannot be subclassed. Swift uses it in its generated Objective-C headers, but we are interested in making this a first-class Objective-C feature.

	* Swift-specific attributes (‘swift_error', ‘swift_name’, ’swift_private'): these attributes affect the mapping of (Objective-)C declarations into Swift.

	* ‘swift’ unavailability: the existing ‘availability’ attribute is extended with a ‘swift’ platform, so that one can mark something as unavailable in Swift.

* API Notes: This represents the bulk of the changes in the repository. API notes solve a not-uncommon problem: we invent some new Clang attribute that would be beneficial to add to some declarations in system headers (e.g., adding a ‘noreturn’ attribute to the C ‘exit’ function), but we can’t go around and fix all of the system headers everywhere. With API notes, we can write a separate YAML file that states that we want to add ‘noreturn’ to the ‘exit’ function: when we feed that YAML file into Clang as part of normal compilation (via a command-line option), Clang will add ‘noreturn’ to the ‘exit’ function when it parses the declaration of ‘exit’. Personally, I don’t like API notes—even with our optimizations, it’s inefficient in compile time and it takes the “truth” out of the headers—but I can see the wider use cases. If the Clang community wants this feature, I can prepare a proper proposal; if not, we’ll keep this code in the Swift clone of Clang and delete it if Swift ever stops needing it.

* SourceMgrAdapter: An adapter that translates diagnostics from an llvm::SourceMgr to clang::SourceManager. This is used by the API notes YAML compiler to translate its diagnostics into something that goes our through Clang’s SourceManager, but might be useful for other clients that are making use of llvm::SourceMgr for simple handling of source files. Unless API notes gets pulled into llvm.org <http://llvm.org/> Clang or someone else asks for it, I don’t feel like this is important to pull into llvm.org <http://llvm.org/> Clang by itself.


Any questions? Feel free to contact me!

	Cheers,
	Doug

[*] The actual ideas were discussed at the 2014 Developer Meeting in the “Skip the FFI” talk by Jordan Rose and John McCall (http://llvm.org/devmtg/2014-10/#talk18 <http://llvm.org/devmtg/2014-10/#talk18>)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151203/81d25359/attachment.html>