[cfe-dev] Clang and Swift

[Anna Zaks via cfe-dev]

> On Dec 7, 2015, at 1:42 AM, Yury Gribov <y.gribov at samsung.com> wrote:
> 
> On 12/05/2015 01:06 AM, Anna Zaks via cfe-dev 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 <mailto: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 <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
> c
> lone 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.
> 
> Will this also support parameter annotations? Otherwise the feature is too crippled.
> 
> On the other hand supporting parameters will cause issues with header/notes compatibility (imagine function interface have been changed at some point and YAML only knows about the last version).
> 

Yes, parameter annotations are supported. 

Currently, the format is only targeting a specific list of annotations such as nullability. However, it can be extended or generalized to cover more:
https://github.com/apple/swift-clang/blob/4deb154edccff8545d801c567628464082e7aeb9/lib/APINotes/APINotesYAMLCompiler.cpp

Here is an example:
https://github.com/apple/swift-clang/blob/4deb154edccff8545d801c567628464082e7aeb9/test/APINotes/Inputs/Frameworks/SomeKit.framework/APINotes/SomeKit.apinotes

Also, only C and Obj-C are currently supported.

>> 
>> 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 <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>)
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>> 
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <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
>> 
>