Skip to content

[silgen] When transforming values into an existential box representat… #17088

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

Conversation

gottesmm
Copy link
Contributor

…ion, do it at +1.

In general, SILGen assumes that only +1 values are "forwarded" into memory. This
is because we want any value that is stored in memory to not be dependent on
other values and for the forwarded object to be able to maintain its own
liveness. So this assert was correct to fire.

The specific test case that exposed this issue is:

What happened here is that we needed to reabstract a loadable value into an
existential and tried to maximally abstract it and thus store it into
memory. The That code was never updated to make sure the value was at +1. So we
would store a guaranteed value into memory and hope that whereever we stored it
doesn't escape the current function. In this case, I believe that we would be
safe... but past returns are not indicators of future results.

rdar://40773543
SR-7858

(cherry picked from commit d2e1bcd)

…ion, do it at +1.

In general, SILGen assumes that only +1 values are "forwarded" into memory. This
is because we want any value that is stored in memory to not be dependent on
other values and for the forwarded object to be able to maintain its own
liveness. So this assert was correct to fire.

The specific test case that exposed this issue is:

What happened here is that we needed to reabstract a loadable value into an
existential and tried to maximally abstract it and thus store it into
memory. The That code was never updated to make sure the value was at +1. So we
would store a guaranteed value into memory and hope that whereever we stored it
doesn't escape the current function. In this case, I believe that we would be
safe... but past returns are not indicators of future results.

rdar://40773543
SR-7858

(cherry picked from commit d2e1bcd)
@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm gottesmm merged commit fab1391 into swiftlang:swift-4.2-branch Jun 10, 2018
@gottesmm gottesmm deleted the swift-4.2-branch-radar40773543 branch June 10, 2018 14:33
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