Skip to content

[Diagnostics] Nullify contextual type if it's generic with type variables #6806

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
Jan 17, 2017

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Jan 14, 2017

It's undesirable to have generic type which contains type variables
as contextual conversion type while diagnosing sub-expressions, it's
going to result in attempt to convert generic arguments to unresolved
type which produces worse diagnostics than no contextual type at all.

Resolves SR-3525.

@xedin
Copy link
Contributor Author

xedin commented Jan 14, 2017

/cc @rudkx @slavapestov

convertType = replaceTypeParametersWithUnresolved(convertType);
convertType = replaceTypeVariablesWithUnresolved(convertType);

bool shouldNullify = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

This is just objectType->is<ArchetypeType>() || objectType->hasUnresolvedType()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I moved both calls down after decision to nullify because we need original types to figure what was what to decide nullification.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And just to clarify a bit, objectType->hasUnresolvedType() is not appropriate in this case standalone, because if it's in a function for example or inout type we still want to preserve it's skeleton because that helps to diagnose inout argument issues. Complete nullification is only appropriate for generic types with unresolved types or standalone archetypes because that's going to give sub-expression solver a chance to try and compute type as it sees and higher level code is going to check it, which avoids error messages like cannot convert (_) -> _ to (Int) -> Void or similar.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, maybe then just factoring this in its own method would be nice. Also please add a comment with the above explanation :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, will do later today, thanks! :)

@slavapestov slavapestov self-assigned this Jan 15, 2017
…bles

It's undesirable to have generic type which contains type variables
as contextual conversion type while diagnosing sub-expressions, it's
going to result in attempt to convert generic arguments to unresolved
type which produces worse diagnostics than no contextual type at all.

Resolves: SR-3525.
@xedin
Copy link
Contributor Author

xedin commented Jan 16, 2017

@slavapestov I've added validateContextualType method to FailureDiagnosis and added all the logic and the comment there.

@slavapestov
Copy link
Contributor

@swift-ci Please smoke test

@slavapestov slavapestov merged commit b8bfd80 into swiftlang:master Jan 17, 2017
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