@swift-ci please test
LGTM!
Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - f46aa1f
Test requested by - @milseman
OS X passed, I'll retry Linux. The master CI test passed.
@swift-ci please test Linux Platform
Login to write a write a comment.
3.0 version of #5025
We have a special case check for the no-escape-by-default rules for a
computed property setter's newValue argument, which if a closure,
obviously has to be escaping. But, we checked this by checking the
type's overall DeclContext, which unfortunately meant we also made
nested closures escaping implicitly. This fixes that to only tack on
the implicit escaping at the top level for the setter's type.
Conflict fixed for 3.0 version.
• Explanation: We have a special case check for the no-escape-by-default rules for a computed property setter's newValue argument, which if a closure, obviously has to be escaping. But, we checked this by checking the type's overall DeclContext, which unfortunately meant we also made nested closures escaping implicitly. This fixes that to only tack on the implicit escaping at the top level for the setter's type.
• Scope of Issue: The bug affects anyone trying to have a computed property of a closure that takes another closure, which is fixed by the PR. But, this PR will affect source compatibility for any code that has a closure computed property that takes another closure as an argument, and relied on it being incorrectly inferred as escaping. However, such code would not compile correctly (crashes SILGen) if used in non-trivial ways.
• Origination: Swift-3, when we added the noescape-by-default rule
• Risk: Low. It’s unlikely that many are exercising this corner case and are relying on the wrong behavior that currently exist. If they are, then they will start crashing the compiler should they use their code in non-trivial ways
• Reviewed By: Doug and Slava
• Testing: Added lit tests
• Directions for QA: none
rdar://problem/28484375