-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Sema: Apply @escaping to typealiases with underlying function type #4347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sema: Apply @escaping to typealiases with underlying function type #4347
Conversation
8467e45
to
c16f5c5
Compare
@swift-ci Please smoke test os x |
c16f5c5
to
adad418
Compare
@swift-ci Please smoke test os x |
1 similar comment
@swift-ci Please smoke test os x |
adad418
to
f0ace02
Compare
@swift-ci Please smoke test os x |
- If a parameter type is a sugared function type, mark the type as non-escaping by default. Previously, we were only doing this if the parameter type was written as a function type, with no additional sugar. This means in the following cases, the function parameter type is now non-escaping: func foo(f: ((Int) -> Void)) typealias Fn = (Int) -> Void func foo(f: Fn) - Also, allow @escaping to be used in the above cases: func foo(f: @escaping ((Int) -> Void)) typealias Fn = (Int) -> Void func foo(f: @escaping Fn) - Diagnose usages of @escaping in inappropriate locations, instead of just ignoring them. It is unfortunate that sometimes we end up desugaring the typealias, but currently there are other cases where this occurs too, such as qualified lookpu of protocol typealiases with a concrete base type, and generic type aliases. A more general representation for sugared types (such as an AttributedType sugared type) would allow us to solve this in a more satisfactory manner in the future. However at the very least this patch factors out the common code paths and adds comments, so it shouldn't be too bad going forward. Note that this is a source-breaking change, both because @escaping might need to be added to parameters with a sugared function type, and @escaping might be removed if it appears somewhere where we do not mark function types as non-escaping by default.
f0ace02
to
79a1512
Compare
@swift-ci Please smoke test os x |
1 similar comment
@swift-ci Please smoke test os x |
This segfaults on the Linux Swift build and breaks the Linux libdispatch build. I'm going to revert in #4369 unless you have a fix in the next few minutes. |
Fix is going through CI now. |
I assume you mean #4368. Does that fix the NSURLSession segfault, the Queue.swift compilation error, or both? |
The Queue.swift compilation error is a separate issue. libdispatch needs an update. Working on that. |
/// setter | ||
static bool isDefaultNoEscapeContext(const DeclContext *DC) { | ||
auto funcDecl = dyn_cast<FuncDecl>(DC); | ||
return !funcDecl || !funcDecl->isSetter(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. What about index parameters of subscripts?
Work in progress. @milseman all that remains is a diagnostic for removing redundant @escaping in non-parameter position, since we decided that's not allowed.