[PATCH] D87331: Sema: add support for `__attribute__((__swift_error__))`

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/include/clang/Basic/Attr.td:2128
+  ];
+  let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
+  let Documentation = [SwiftErrorDocs];
----------------
rjmccall wrote:
> compnerd wrote:
> > aaron.ballman wrote:
> > > Should this apply to function-like things such as blocks or function pointers? If so, you should use `HasFunctionProto`.
> > I believe not.
> Correct, it's just declared functions for now.
SGTM, thank you for verifying.


================
Comment at: clang/include/clang/Basic/AttrDocs.td:3394
+parameter. Currently, the error parameter is always the last parameter of type
+``NSError**`` or ``CFErrorRef*``.  Swift will remove the error parameter from
+the imported API. When calling the API, Swift will always pass a valid address
----------------
compnerd wrote:
> rjmccall wrote:
> > compnerd wrote:
> > > aaron.ballman wrote:
> > > > Canonical type or are typedefs to these types also fine? May want to mention that the type has to be cv-unqualified, but I do wonder whether something like `NSError * const *` is fine.
> > > I am definitely not the authority on this, but I believe that the common thing is to take `NSError **` or `CFErrorRef **` by canonical name.  The cv-qualified versions, except on the outermost pointer, is something that can be treated as valid, though it is certainly extremely unusual.  I've added test cases for them as well.
> > `NSError * const *` actually does not really work; the whole point is that this is an out-parameter.
> Oh right, its the `const NSError ** const` that can work, because the outer pointer can be non-mutable as it is a pointer by-reference scenario.  Should we diagnose the `NSError * const *` case then?  Any `const` qualified value is really unidiomatic to say the least.
I think we should diagnose (as an error) any case that can't work.

I think it may make sense to diagnose (as a warning) any case where we want to ignore the qualifiers, in case we want to give semantics to those qualifiers in this situation later. So this means we'd error on `NSError * const *` but warn and ignore the qualifiers on `volatile NSError **`. However, I don't insist on warning in this case unless there's a situation that the user might actually appreciate the warning because it matters (it's not clear to me if such a situation exists). Also, it's not clear to me whether we should or should not warn on a `restrict`-qualified pointer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87331/new/

https://reviews.llvm.org/D87331