Skip to content

[CS] Fix key path dynamic member IUOs #28562

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 4 commits into from
Dec 4, 2019

Conversation

hamishknight
Copy link
Contributor

Previously we were only handling IUO unwrapping in visitKeyPathExpr, but not for callers that were building their own property and subscript components such as dynamic member lookup.

This PR moves the IUO unwrapping logic into buildKeyPath[Property/Subscript]Component, and adjusts their signatures to allow them to append multiple components. It also adds buildKeyPathOptionalForceComponent to allow more convenient adding of an optional force component.

Resolves SR-11893.

When originally implemented (a5ca6cc),
we used to append the set `component` to
`resolvedComponents`, however that appears to have
been refactored away at some point, leaving a couple
of dead assignments. Restore the old behaviour by
just appending the components.
Rather than setting `baseTy` for each component,
just set it for the last component in the
iteration. In addition, remove the `component`
variable, which no longer serves a purpose.
Finally, cache all the component types at the end
of the loop.
Previously we were only handling IUO unwrapping in
visitKeyPathExpr, but not for callers that were
building their own property and subscript
components such as dynamic member lookup.

Move the IUO unwrapping logic into
buildKeyPath[Property/Subscript]Component,
and adjust their signatures to allow them to
append multiple components. Also add
buildKeyPathOptionalForceComponent to allow more
convenient adding of an optional force component.

Resolves SR-11893.
Previously we missed caching component types in
one case, and cached the wrong type in another.
Make both cases use cacheExprTypes to cache the
correct component types.
@hamishknight hamishknight requested a review from xedin December 4, 2019 16:49
@hamishknight
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

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