Skip to content

[4.2] DI: Consider capture of lets to be a read-only use. #17111

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
merged 2 commits into from
Jun 11, 2018

Conversation

jckarter
Copy link
Contributor

SILGen emits capture of an address-only let property as @inout_aliasable, but Sema enforces that the closure is not really allowed to modify the property, so DI can consider the capture to be a read. Fixes rdar://problem/40828667.

A more principled solution would be to treat let captures as @in_guaranteed (see #17047), but that unfortunately leads to breakage elsewhere in the optimizer.

jckarter added 2 commits June 11, 2018 10:54
This fixes a subtle issue where, during single-expression closure type inference, we would ask for the settability of local variables from the outer function's context, leading us to mistakenly consider them mutable inside single-expression closure contexts. DI would catch some but not all violations of the expected semantics here.
Sema enforces that closures can't modify the let properties of their captured contexts, but we consider the capture argument to be @inout_aliasable at the SIL level. Add an exception to our normal handling so that this use is considered read-only. Fixes rdar://problem/40828667.

A more principled solution would be to treat let captures as @in_guaranteed (see swiftlang#17047), but that unfortunately leads to breakage elsewhere in the optimizer.
@jckarter
Copy link
Contributor Author

@swift-ci Please test

@jckarter
Copy link
Contributor Author

@swift-ci Please test source compatibility

@jckarter jckarter merged commit e6273de into swiftlang:swift-4.2-branch Jun 11, 2018
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.

1 participant