[cfe-dev] Clang and Swift

Fri Dec 4 14:46:51 PST 2015

Without having looked into it...

If people need a feature like this, I'm wondering if it would make sense to
parse a special file containing normalish C/C++/ObjC declarations, and use
those to replace or augment attributes from matching declarations in the
normal parse. Requiring a special YAML and binary format reader/writer
seems unfortunate, especially as it looks nowhere close to being
generically useful, beyond exactly what Swift needed.

I must also admit to being a bit surprised that Apple needed to ship a
feature like this at all, since I'd have thought you/they would have had
full control over their own platform's header files, and could've just
committed the changes to that directly. :)

On Fri, Dec 4, 2015 at 5:06 PM, Anna Zaks via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> On Dec 3, 2015, at 5:18 PM, Sean Silva via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
>
>
>
> 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!
>
>
> +1
>
> API Notes is great for adding annotations to declarations when/before
> changes to header files can be made. I can see how this could be used by
> the future clang static analyzer checks.
>
> Anna.
>
>
> -- 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
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> 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/20151204/9b19fa94/attachment.html>