<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 16, 2020 at 4:28 PM James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">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">On Thu, Oct 15, 2020 at 11:59 PM Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div>On Oct 14, 2020, at 6:49 PM, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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 class="gmail_quote"><div><br>If such a hook mechanism is added, it then seems entirely plausible that <a href="https://github.com/apple/llvm-project/blob/apple/main/clang/lib/Sema/SemaAPINotes.cpp" target="_blank">SemaAPINotes.cpp</a> and<span> </span><a href="https://github.com/apple/llvm-project/tree/apple/main/clang/lib/APINotes" target="_blank">lib/APINotes/*</a> can be moved from the clang-fork into swift itself without requiring significant modifications of the code, or any change in functionality of the feature.</div></div></div></blockquote><div><br></div><div>Well, the APINotes also provide nullability information for ObjC interfaces, which is not part of Swift, but rather part of ObjC, so that still needs to be in clang.  That is, the functionality is useful for ObjC, and that doesn't make sense to be in Swift.</div><div></div></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Theoretically one could imagine doing so -- but TTBOMK, it's never actually been used like this. All nullability annotations used by objc compilations live in the headers themselves, and the apinotes command-line options are passed only by Swift, for creating a Swift-ObjC-bridge module.<span> </span></div></div></blockquote><br></div><div>Nullability isn’t just useful for swift, it is also useful to the clang static analyzer and other tools that want to reason about C API semantics.</div></div></blockquote><div><br></div><div>Nullability is being used in ObjC to emit warnings, but apinotes is not. For ObjC compiles (and static analyzer), the nullability information comes from header files, _Nullable and _Nonnull keywords, "NS_ASSUME_NONNULL_BEGIN", etc.</div></div></div></blockquote><div><br></div><div>It could be useful, however, to annotate a parameter of a C function as "nonnull" with APINotes. Take for example the GNU libc implementation for the POSIX 'getsockname' function, which does not have the __nonnull attribute written in the declaration, even though semantically the 2nd and 3rd arguments should never be NULL. </div><div><font face="monospace">  extern int getsockname (int __fd, __SOCKADDR_ARG __addr, socklen_t *__restrict __len) __THROW;</font><br></div><div>This is another use-case for the static analyzer, if we could describe this in an additional YAML file. Strictly speaking, we can provide this information hardcoded in the static analyzer code (as we do now), but this feature could be useful for other libraries. I mean either we can provide the annotations in the headers themselves or in additional APINotes or we hardcode them in the static analyzer code.</div></div></div>