[cfe-dev] Adding Support for APINotes
Saleem Abdulrasool via cfe-dev
cfe-dev at lists.llvm.org
Fri Oct 9 13:13:09 PDT 2020
Yes, I agree that the initial consumer of this functionality will be
Swift. However, the functionality itself should not be considered entirely
specific to Swift. Although I do not plan on currently extending it,
patches to extend it beyond just Swift and adding new consumers would be
On Tue, Oct 6, 2020 at 6:39 AM James Y Knight <jyknight at google.com> wrote:
> Every time this discussion has recurred, people have noted that a feature
> like this could be valuable for many use-cases beyond swift. And I don't
> disagree. But, what we actually have here is far from a generic "extra API
> information" solution. It has a lot of missing functionality, without even
> a clear path towards adding it. And, many of the features which it does
> have are extremely swift-specific. What has been built here is clearly
> purpose-designed just for Swift/ObjC-interop, and it does not really seem
> realistic to me to expect this to be able to accomplish people's wider
> dreams of a generally-useful API sidecar mechanism.
> One of the clearest examples of a feature which is strikingly out-of-place
> as an upstream feature is the "SwiftVersions" stanza, and correspondingly,
> -fapi-notes-swift-version command-line argument -- but that's hardly the
> only such issue. I could come up with ideas on how to avoid needing such a
> weird thing, but I think that would probably not be productive.
> Because, I think the question which is being actually being implicitly
> asked in this thread is:
> Is the Clang community OK with adding this (hefty!) amount of code to
> support a feature which is currently -- and most likely will remain -- only
> useful for Swift? Furthermore, is it OK to add essentially as-is, with no
> ability to significantly affect the design? Incompatible changes would then
> break the deployed Swift usage, and therefore cannot be accepted.
> Quite possibly the answer to both is indeed "yes". Personally, I am
> vaguely uncomfortable with this, but not entirely opposed to including it
> on those grounds.
> Yet, what I definitely do not want to see is this getting pushed upstream
> _without_ it explicitly being stated that the above is what's happening. We
> need to acknowledge that what is actually being proposed here is
> "SwiftAPINotes", not "APINotes", and for people to be OK with that.
> (And, as a sidenote, it also seems unclear to me that Swift really needed
> APINotes to be put into Clang (even Swift's fork of Clang) vs building the
> similar functionality into the Swift consumer of the Clang AST. Possibly
> this was an arbitrary choice made early on. Or maybe there's good reasons
> why it wouldn't work to do that way which aren't obvious at a quick glance.
> Bu, I suspect there is no appetite for making such a large design change
> now, even if it could've been better, so that's not really a useful
> discussion to have.)
> On Mon, Sep 28, 2020 at 5:10 PM Saleem Abdulrasool via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>> I'd like to revive the effort around merging APINotes support into the
>> llvm.org repository. This was previously discussed at
>> http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html nearly 3
>> years ago. The overall consensus seemed neutral to slightly positive. Now
>> that the Swift specific attributes have been merged, the APINotes seem like
>> a good next step towards converging the fork.
>> I've put up https://reviews.llvm.org/D88446 to add initial documentation
>> on the feature before trying to add the actual implementation with the
>> goal of gathering commits on the technical aspects of the feature.
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev