Skip to content

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

Merged

Conversation

slavapestov
Copy link
Contributor

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.

@slavapestov slavapestov force-pushed the noescape-by-default-typealias-fix branch from 8467e45 to c16f5c5 Compare August 17, 2016 20:11
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test os x

@slavapestov slavapestov force-pushed the noescape-by-default-typealias-fix branch from c16f5c5 to adad418 Compare August 17, 2016 20:29
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test os x

1 similar comment
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test os x

@slavapestov slavapestov force-pushed the noescape-by-default-typealias-fix branch from adad418 to f0ace02 Compare August 18, 2016 01:57
@slavapestov
Copy link
Contributor Author

@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.
@slavapestov slavapestov force-pushed the noescape-by-default-typealias-fix branch from f0ace02 to 79a1512 Compare August 18, 2016 02:37
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test os x

1 similar comment
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test os x

@gparker42
Copy link
Contributor

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.

@slavapestov
Copy link
Contributor Author

Fix is going through CI now.

@gparker42
Copy link
Contributor

I assume you mean #4368. Does that fix the NSURLSession segfault, the Queue.swift compilation error, or both?

@slavapestov
Copy link
Contributor Author

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();
Copy link
Contributor

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?

@slavapestov slavapestov deleted the noescape-by-default-typealias-fix branch August 19, 2016 05:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants