Verify noescape closures for exclusivity diagnostics.

[atrick]

Verify @inout_aliasable captures.

This is currently only done in DiagnoseStaticExclusivity because AllocBoxToStack
doesn't know how to set @NoEscape function types yet.

Negative test cases need to be added. This PR is currently just for SCK testing and review.

[atrick]

@swift-ci Test Source Compatibility.

[slavapestov]

What are inout_aliasable captures actually used for these days?

[atrick]

@slavapestov @inout_aliasable is for any captured variable that's promoted to the stack (unboxed). SILGen emits them in the obvious cases. The reason they need to be verified is that exclusivity checking is completely different in those cases. There aren't any access markers in the SIL. Instead it is assumed that the diagnostic pass can detect all closure applications and analyze the body of the closure. So, this verification is required to guard against undefined behavior.

Incidentally, I was working on removing the @inout_aliasable convention on a branch, relying on the @NoEscape attribute instead, removing the special logic from SILGen, and unifying several passes, but I can't enable any of that until exclusivity is officially part of the language.

[atrick]

This passed SCK testing. I think we can enable this verification now by default in debug builds.

[atrick]

@swift-ci test.

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - cc42bbbdba67b3eaa6180b4d83d9683966769ddb

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - cc42bbbdba67b3eaa6180b4d83d9683966769ddb

[atrick]

@swift-ci test.

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 2bcf726d091b4d2d5bbf8a4460966f31003cb9e1

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 2bcf726d091b4d2d5bbf8a4460966f31003cb9e1

[slavapestov]

@atrick What does it mean for exclusivity to be part of the language model? I thought it was already.

[atrick]

@slavapestov It's part of the language but the compiler can't make that assumption yet. We don't want to make it undefined behavior until there's some arbitrary level of confidence that code doesn't break it in practice.

[atrick]

The test failure is unrelated to this PR.

[slavapestov]

@atrick I see, so basically once exclusivity checking is complete you plan on changing the optimizer to start assuming it?

[atrick]

@slavapestov We won't make assumptions that lead to memory unsafety or undefined behavior yet. Enforcement needs to be adequate in Swift 5 if we ever want to make those assumptions.

[atrick]

@devincoughlin Does this look ok?

[devincoughlin]

Looks great!

[atrick]

@swift-ci test and merge.