Skip to content

[SILGen] Don't assume physical lvalue components are side effect free #14410

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 1 commit into from
Mar 1, 2018

Conversation

hamishknight
Copy link
Contributor

@hamishknight hamishknight commented Feb 5, 2018

When emitting an ignored expression (such as the argument to type(of:)), we try not perform a load of an lvalue if we can prove that loading has no observable side effects. Previously we based this on whether the components of the lvalue are physical, however some physical components, such as force unwrapping and key-paths, have side effects (the former can trap, the latter can call arbitrary getters & setters).

This PR introduces and uses a new method to determine whether a component has side effects, meaning that ignored expressions with e.g force unwrap and key-path lvalue components (see SR-1327 for examples) will have their side effects correctly evaluated.

In addition, this PR adds an additional case to emitIgnoredExpr to avoid loading in cases where we have a force unwrap of an lvalue load (instead, if possible, try to emit the precondition using the lvalue address).

Resolves SR-1327.

When emitting an ignored expression, we try not perform a load of an lvalue if we can prove that loading has no observable side effects. Previously we based this on whether the components of the lvalue are physical, however some physical components (such as force unwrapping and key-paths) have side effects.

This commit introduces a new method to determine whether a component has side effects, and also adds an additional case to `emitIgnoredExpr` to avoid loading in cases where we have a force unwrap of an lvalue load (instead, if possible, try to emit the precondition using the lvalue address).
@hamishknight
Copy link
Contributor Author

@jckarter I'm not sure who to request a review from for this, would either yourself or someone else be available?

@jckarter
Copy link
Contributor

Looks good to me.

@jckarter
Copy link
Contributor

@swift-ci Please test

@hamishknight
Copy link
Contributor Author

@jckarter Is this good to merge?

@jckarter jckarter merged commit f4caa5c into swiftlang:master Mar 1, 2018
@jckarter
Copy link
Contributor

jckarter commented Mar 1, 2018

Yes, thanks!

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