<div dir="ltr"><div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div>Because, I think the question which is being actually being implicitly asked in this thread is:</div><div>  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.</div><div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div>(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.)</div><div></div></div><div><div></div></div><div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 28, 2020 at 5:10 PM Saleem Abdulrasool via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi!<div><br></div><div>I'd like to revive the effort around merging APINotes support into the <a href="http://llvm.org/" target="_blank">llvm.org</a> repository.  This was previously discussed at <a href="http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html</a> 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.</div><div><br></div><div>I've put up <a href="https://reviews.llvm.org/D88446" target="_blank">https://reviews.llvm.org/D88446</a> 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.</div><div><br></div><div>Thanks.</div><font color="#888888"><div></div></font><div><br></div>-- <br><div dir="ltr">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>