Skip to content

[TypeChecker] Fix crash with Objective C keypaths. #17497

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
Jun 26, 2018
Merged

[TypeChecker] Fix crash with Objective C keypaths. #17497

merged 2 commits into from
Jun 26, 2018

Conversation

rudkx
Copy link
Contributor

@rudkx rudkx commented Jun 26, 2018

We have a crash reported but do not have a test case and my attempt at
creating one was unsuccessful. It seems like the issue is that we have
an invalid decl that we attempt to access the interface type on,
though, so hopefully this fixes the issue.

I also tweaked the constraint generator to bail out when
checkObjCKeyPathExpr fails.

Potentially fixes: rdar://problem/40955755

We have a crash reported but do not have a test case and my attempt at
creating one was unsuccessful. It seems like the issue is that we have
an invalid decl that we attempt to access the interface type on,
though, so hopefully this fixes the issue.

I also tweaked the constraint generator to bail out when
checkObjCKeyPathExpr fails.

Potentially fixes: rdar://problem/40955755
@rudkx rudkx requested a review from slavapestov June 26, 2018 00:52
@rudkx
Copy link
Contributor Author

rudkx commented Jun 26, 2018

@swift-ci Please smoke test

@@ -3280,7 +3280,8 @@ namespace {
if (auto keyPath = dyn_cast<KeyPathExpr>(expr)) {
if (keyPath->isObjC()) {
auto &cs = CG.getConstraintSystem();
(void)cs.getTypeChecker().checkObjCKeyPathExpr(cs.DC, keyPath);
if (!cs.getTypeChecker().checkObjCKeyPathExpr(cs.DC, keyPath))
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we emit a diagnostic when this returns false?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, at least in the cases we already hit this in during test runs.

@@ -317,6 +317,8 @@ Optional<Type> TypeChecker::checkObjCKeyPathExpr(DeclContext *dc,
// Handle property references.
if (auto var = dyn_cast<VarDecl>(found)) {
validateDecl(var);
if (var->isInvalid() || !var->hasInterfaceType())
Copy link
Contributor

Choose a reason for hiding this comment

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

Try a property with no declared type and an initial value expression that references itself via a keypath

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be clear, I can get this code to be hit, but not with a nullptr interface type. Instead, we have an error type.

I'll push another commit that checks explicitly for error types and adds a test case that exercises that path.

It would be nice to understand how this was actually reaching this point with a null type, though - it's probably indicative of some bad path in decl validation.

And add a test that exercises this exit path (although it won't crash
a compiler without my fixes because we do end up with ErrorType in
that case, not a nullptr).
@rudkx
Copy link
Contributor Author

rudkx commented Jun 26, 2018

@swift-ci Please smoke test and merge

@rudkx
Copy link
Contributor Author

rudkx commented Jun 26, 2018

@swift-ci Please smoke test

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