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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
