[3.0 compat] Don't diagnose @escaping var-arg closures. #5243
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Var-arg closures are already escaping, so we typically want to issue an error if @escaping is specified. To not do sure will confuse and give a false impression on the un-annotated semantics and whether it is needed. But, 3.0 shipped with a bug where we didn't consistently apply the no-escape-by-default rule here, and thus it was semantically meaningful (and needed). In order to preserve source compatibility, albeit at the expense of developers on versions 3.0.1 and later in the Swift 3 family, we suppress the error if we see @escaping. Either way, this is a relatively uncommon usage, so the confusion won't be too wide spread.
The recent @escaping on variadic argument closures back-compat fix is the first Swift 3.0 compatibility behavior that we don't want to carry forwards indefinitely into the future. To address this, we version-gate the diagnostic suppression. Makes it an official compatibility check. Creates new test directory for compatibility testing. Allow -swift-version 4 so that we can test it both ways.
|
@swift-ci please smoke test |
|
@graydon or @DougGregor, or whoever care about how we roll out the version checking and testing, please review. |
|
@swift-ci please smoke test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[3.0 compat] Don't diagnose @escaping var-arg closures.
Var-arg closures are already escaping, so we typically want to issue
an error if @escaping is specified. To not do sure will confuse and
give a false impression on the un-annotated semantics and whether it
is needed. But, 3.0 shipped with a bug where we didn't consistently
apply the no-escape-by-default rule here, and thus it was semantically
meaningful (and needed).
In order to preserve source compatibility, albeit at the expense of
developers on versions 3.0.1 and later in the Swift 3 family, we
suppress the error if we see @escaping. Either way, this is a
relatively uncommon usage, so the confusion won't be too wide spread.
[swift-version] Allow swift-version 4 and tests
The recent @escaping on variadic argument closures back-compat fix is
the first Swift 3.0 compatibility behavior that we don't want to carry
forwards indefinitely into the future. To address this, we
version-gate the diagnostic suppression.
Makes it an official compatibility check. Creates new test directory
for compatibility testing. Allow -swift-version 4 so that we can test
it both ways.
Note: The swift-3 branch PR was already merged at #5217