[cfe-dev] Adding Support for APINotes

[Chris Lattner via cfe-dev]

On Oct 6, 2020, at 6:39 AM, James Y Knight via cfe-dev <cfe-dev at lists.llvm.org> 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.)

I think that is a fairly reasonable characterization from what I know, but I would go a bit further - we don’t always make “perfection” be the barrier to landing something in mainline;  we make “good enough” be the threshold.  Is the current implementation of APINotes a useful baseline that can be extended in the future?

-Chris