erik.pilkington added inline comments.
================ Comment at: clang/lib/Sema/SemaDeclAttr.cpp:5977 + checkSwiftAsyncErrorBlock(S, D, ErrorAttr, AsyncAttr); +} + ---------------- aaron.ballman wrote: > Should there be a diagnostic to combine `swift_error` and `swift_async_error` > on the same function? Similarly, should there be a diagnostic when adding > `swift_async_error` to a function that isn't (eventually) marked > `swift_async`? My understanding is that `swift_error` and `swift_async_error` don't conflict with each other. `swift_error` describes how the non-async swift function handles errors, whereas `swift_async_error` describes how the swift async function handles errors. Since both swift functions are generated, I think it can make sense to have both attributes on one ObjC function. I think it can make sense to have `swift_async_error` without `swift_async`, since the swift importer infers some functions are async without the `swift_async` attribute using heuristics based on parameter names. I guess we could mimic those heuristics here to diagnose when `swift_async_error` doesn't make sense alone, but ISTM that it makes more sense to do that check in the swift importer. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96175/new/ https://reviews.llvm.org/D96175 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits