Skip to content

Teach SubstitutionMap::isIdentity about non-canonical generic params #25767

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
Jun 26, 2019

Conversation

jrose-apple
Copy link
Contributor

Do a weaker check here that only looks at the canonical generic params and guarantees that those substitute to themselves. There may be replacement types for other generic params too, to canonicalize them, but that's not a problem.

This fixes a crash trying to mangle decls with opaque result types that have generic signatures that canonicalize away a generic parameter.

rdar://problem/51775857

@jrose-apple
Copy link
Contributor Author

Can you think of any other interesting test cases that I didn't include?

@swift-ci Please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - d2d6631e823d93dc0bf85be7c3efc7bc0b20dfc2

return;

unsigned ordinal = sig->getGenericParamOrdinal(paramTy);
auto replacement = getReplacementTypes()[ordinal]->getCanonicalType(sig);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be clearer if you just did Type(paramTy).subst(this)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's not the same check, is it? That would also accept SubstitutionMaps that didn't have an entry for that parameter.

Copy link
Contributor

Choose a reason for hiding this comment

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

SubstitutionMaps are always "complete". There's an entry for each parameter

});

return !hasNonIdentityReplacement &&
countOfGenericParams == getReplacementTypes().size();
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it ever possible for countOfGenericParams to not equal getReplacementTypes().size()? Maybe it should be an assertion instead?

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 was wondering that, but I didn't know if it was safe. All valid SubstitutionMaps should behave like that, but what about a degenerate one?

Copy link
Contributor

Choose a reason for hiding this comment

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

See above :)

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - d2d6631e823d93dc0bf85be7c3efc7bc0b20dfc2

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - d2d6631e823d93dc0bf85be7c3efc7bc0b20dfc2

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - d2d6631e823d93dc0bf85be7c3efc7bc0b20dfc2

@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test

Do a weaker check here that only looks at the canonical generic params
and guarantees that *those* substitute to themselves. There may be
replacement types for other generic params too, to canonicalize them,
but that's not a problem.

This fixes a crash trying to mangle decls with opaque result types
that have generic signatures that canonicalize away a generic
parameter.

rdar://problem/51775857
@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test

@jrose-apple jrose-apple merged commit 8157ccf into swiftlang:master Jun 26, 2019
@jrose-apple jrose-apple deleted the mistaken-identity branch June 26, 2019 20:09
jrose-apple added a commit to jrose-apple/swift that referenced this pull request Jun 26, 2019
…wiftlang#25767)

Do a weaker check here that only looks at the canonical generic params
and guarantees that *those* substitute to themselves. There may be
replacement types for other generic params too, to canonicalize them,
but that's not a problem.

This fixes a crash trying to mangle decls with opaque result types
that have generic signatures that canonicalize away a generic
parameter.

rdar://problem/51775857
(cherry picked from commit 8157ccf)
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