[cfe-dev] Clang and Swift

[Sean Silva via cfe-dev]

On Thu, Dec 3, 2015 at 2:45 PM, Douglas Gregor via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi all,
>
> As some of you may have heard, Swift has gone open-source over at
> 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 Clang repository over on GitHub at
> github.com/apple/swift-clang. We merge regularly and try to minimize our
> differences with llvm.org's Clang—for more information on how we’re
> handling this, see 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 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.
>

Internally I recently saw a situation that would have benefitted from this
sort of thing. Essentially Sean Eveson (CC'd) and his coworkers were
prototyping some static analyzer checks that required certain functions in
the SDK to be marked up with some info (really not much more than the moral
equivalent of an "printf" attribute). Obviously there's a catch-22 with
proving the checks are valuable and getting the corresponding API's
officially marked up with such attributes (and such updated headers making
to all clients, etc.).

This sort of feature would help break that catch-22 and avoid the need for
ad-hoc hardcoded tables. Having all that PS4-specific data hardcoded was
actually the primary barrier to upstreaming the check (or at least getting
a proper upstream review of the idea), so having a way to decouple those
private annotations would have really been nice!

-- Sean Silva


>
> * 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 Clang or someone else asks for it, I
> don’t feel like this is important to pull into 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)
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151203/b73f23a5/attachment.html>