[cfe-dev] Adding Support for APINotes

[Saleem Abdulrasool via cfe-dev]

Hi James,

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
welcome.

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:
>
>> Hi!
>>
>> 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.
>>
>> Thanks.
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201009/72e28c72/attachment.html>