aaron.ballman added inline comments.
================ Comment at: clang/include/clang/Basic/AttrDocs.td:3387 +The ``swift_objc_members`` attribute maps to the ``@objcMembers`` Swift +attribute, which indicates that Swift members of this class, its subclasses, and +all extensions thereof, will implicitly be exposed back to Objective-C. ---------------- gribozavr2 wrote: > aaron.ballman wrote: > > The documentation is a bit hard to follow -- the user is going to be adding > > this attribute to an ObjC interface, so the docs should be talking about > > what that means from the ObjC side of things more so than the Swift side, > > no? > IIUC, this attribute has no effect on the Objective-C users of this type. It may not have semantic impact on the ObjC side of things, but I'd still expect that since the user is writing it on an ObjC entity, the docs talk about it from that perspective. e.g., I'd expect the documentation to be more along the lines of "The attribute indicates that the members of this Objective-C class/protocol/whatever, its subclasses and so on, will be exposed as Swift class members that do the awesome thing." instead of "In Swift, this other attribute does things similar to what this one does in Objective-C." ================ Comment at: clang/test/SemaObjC/attr-swift_objc_members.m:4 +#if !__has_attribute(swift_objc_members) +#error cannot verify precense of swift_objc_members attribute +#endif ---------------- gribozavr2 wrote: > aaron.ballman wrote: > > gribozavr2 wrote: > > > > > The typo fix makes sense to me, but for my own understanding, why switch to > > a string literal? > IIUC, as it is now, the message is tokenized by the lexer -- and I think > that's not the intent, none of these words are program code. Interesting and somewhat different from my understanding. My mental model for `#error` is that it "replays" the tokens into the diagnostic message up to the end of the line. Given that I prefer my diagnostics to be `warning: you did the wrong thing` and not `warning: "you did the wrong thing"` (with quotes), I usually leave the quotes off so that the error looks more consistent with other errors. Neither form is more right than the other in this case, so I don't really care for this review (I was interested in it as a standards committee member who recently had to look at the specification for `#error` though). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87395/new/ https://reviews.llvm.org/D87395 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
