[cfe-dev] Adding Support for APINotes

[James Y Knight via cfe-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201006/f462177a/attachment.html>