<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 6, 2020, at 9:39 AM, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Because, I think the question which is being actually being implicitly asked in this thread is:</div><div class=""> 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 class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><div class="">(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></blockquote><div><br class=""></div><div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">IIUC APINotes wants to add attributes during parsing so that the those attributes are then treated just like real parsed attributes would be by Sema. </div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Ideally this sort of thing should be able to be contained in an ASTConsumer, but it presently cannot: the only real option ASTConsumer provides is to traverse the AST post-parsing in an override of `HandleTranslationUnit()`. This leaves APINotes no choice but to add its details directly to Sema and Parser, with the result that Swift-specific details would necessarily show up in the guts of mainline clang were this to be upstreamed. </div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">If ASTConsumer instead provided a comprehensive virtual interface (but with negligible overhead, somehow) to perform custom consumer actions at strategic points during parsing/Sema (e.g., call consumer virtuals in each Sema::ActOn*), this conflict probably could be, or at least could have been, avoided.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Note too that this issue resonates with one a user faced just the other day: he wanted to call `Sema::LookupName` within an ASTMatchers callback (during HandleTranslationUnit, as usual) to determine if a certain node could be rewritten w/o changing its semantics — but of course the necessary Sema/Parser scope info is long gone by that point. If only he had the option to perform his logic on the node immediately after it was parsed, there would be no issue. Because he cannot, his only option was to laboriously recreate that state data in order to call LookupName.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">In sum, the dearth of ASTConsumer virtuals hinder encapsulation, causing 1) Sema and Parser to be polluted with what should be a consumer’s details, and 2) consumers to be polluted with what should be Sema & Parser details, and making it difficult to upstream useful tools.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""></div></div><div class=""><div class=""></div></div><div class=""><div class=""></div></div></div><br class=""><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" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></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" class=""><div dir="ltr" class="">Hi!<div class=""><br class=""></div><div class="">I'd like to revive the effort around merging APINotes support into the <a href="http://llvm.org/" target="_blank" class="">llvm.org</a> repository. This was previously discussed at <a href="http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html" target="_blank" class="">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 class=""><br class=""></div><div class="">I've put up <a href="https://reviews.llvm.org/D88446" target="_blank" class="">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 class=""><br class=""></div><div class="">Thanks.</div><font color="#888888" class=""><div class=""></div></font><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div></div></div>
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>