Skip to content

[Sema] Correct lvalue computation in buildStorageRef for synthesizing local accessors. #34230

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
Oct 8, 2020

Conversation

hborla
Copy link
Member

@hborla hborla commented Oct 7, 2020

This is a follow-up to the local property wrapper implementation to address #34109 (comment)

The fix turned out to be pretty simple - the lvalue adjustment for the storage reference base simply needed to be moved earlier and slightly adjusted to account for cases where the base is not self.

@hborla hborla requested a review from slavapestov October 7, 2020 23:22
@hborla
Copy link
Member Author

hborla commented Oct 7, 2020

@swift-ci please smoke test

@hborla hborla merged commit a7a47e5 into swiftlang:main Oct 8, 2020
@hborla hborla deleted the build-storage-ref-lvalue branch October 8, 2020 15:59
CodaFi added a commit to CodaFi/swift that referenced this pull request Jul 6, 2021
AutoClosureExprs created by the constraint system used to be constructed
with the decl context of the constraint system itself. This meant that
autoclosures in expressions nested in closures would initially be
parented onto any enclosing functions rather than the deepest closure
context. When we ran capture analysis and lookup from inside of the body
of these nascent values, we would fail to find declarations brought into
scope by those parent closures. This is especially relevant when
pre-typechecked code is involved since captures for those declarations
will be forced before their bodies have been recontextualized. See
issue swiftlang#34230 for why we need to force things so early.

The attached test case demonstrates both bugs: The former a bogus lookup
through the parent context that would incorrectly reject this otherwise
well-formed code. The latter is a crash in SILGen when the capture
computation would fail to note $0.

Use the decl context of the solution application target, which is always
going to be the deepest user-written closure expression available to us,
and therefore the deepest scope that can introduce capturable variables.

rdar://79248469
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.

2 participants