[cfe-dev] Adding Support for APINotes

[Gábor Márton via cfe-dev]

On Fri, Oct 16, 2020 at 4:28 PM James Y Knight via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Thu, Oct 15, 2020 at 11:59 PM Chris Lattner <clattner at nondot.org>
> wrote:
>
>> On Oct 14, 2020, at 6:49 PM, James Y Knight via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>
>>>> If such a hook mechanism is added, it then seems entirely plausible
>>>> that SemaAPINotes.cpp
>>>> <https://github.com/apple/llvm-project/blob/apple/main/clang/lib/Sema/SemaAPINotes.cpp>
>>>>  and lib/APINotes/*
>>>> <https://github.com/apple/llvm-project/tree/apple/main/clang/lib/APINotes> 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.
>>>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>
> 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.
>

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.
  extern int getsockname (int __fd, __SOCKADDR_ARG __addr, socklen_t
*__restrict __len) __THROW;
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201016/82d8c1cc/attachment-0001.html>