Skip to content

Fix property wrapper crasher #27619

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
Oct 12, 2019

Conversation

beccadax
Copy link
Contributor

@beccadax beccadax commented Oct 11, 2019

Due to insufficiently robust argument emission code, certain combinations of language features could cause a call to a property wrapper backing initializer to prepare the argument incorrectly, causing an assertion failure in SILGenApply. This commit moves SILGenFunction::emitApplyOfPropertyWrapperBackingInitializer() into SILGenApply so it can use CallEmission and PreparedArguments to emit the call with full generality.

Fixes rdar://problem/55995892.

(I'm going to be honest: SIL-level generics are not my strong suit. I rewrote this function with full generality because I don't know how to fix it in a more targeted way, but I could be doing something very wrong that happens to pass all of our tests. Reviewers, please examine it closely.)

Due to insufficiently robust argument emission code, certain combinations of language features could cause a call to a property wrapper backing initalizer to have mismatched argument types, causing an assertion failure in SILGenApply. This commit moves SILGenFunction::emitApplyOfPropertyWrapperBackingInitializer() into SILGenApply so it can use CallEmission and PreparedArguments to emit the call with full generality. Fixes rdar://problem/55995892.
@beccadax
Copy link
Contributor Author

@swift-ci please smoke test

@beccadax beccadax requested review from gottesmm and removed request for DougGregor October 11, 2019 05:22
Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

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

Looks correct to me, thank you!

LookUpConformanceInModule(varDC->getParentModule()));
}

FormalEvaluationScope writebackScope(*this);
Copy link
Contributor

Choose a reason for hiding this comment

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

You may want an argument scope here instead of a FormalEvaluationScope: @slavapestov your thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

Or actually, that may already be in CallEmission. I forgot.

Copy link
Contributor Author

@beccadax beccadax Oct 11, 2019

Choose a reason for hiding this comment

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

It looks like CallEmission::apply() calls CallEmission::applyFirstLevelCallee(), which calls CallEmission::applyNormalCall(), which creates an ArgumentScope before it calls CallEmission::emitArgumentsForNormalApply(). So I think ArgumentScope is covered, if I understand its purpose correctly.

@beccadax beccadax merged commit f44077b into swiftlang:master Oct 12, 2019
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.

3 participants