Skip to content

Fixing some questionable uses of Type::subst() #8497

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
Apr 18, 2017

Conversation

slavapestov
Copy link
Contributor

No description provided.

OriginalParamSubs = CallerParamSubs;

HasUnboundGenericParams = !SpecializedGenericSig->areAllParamsConcrete();
createSubstitutedAndSpecializedTypes();
Copy link
Contributor

Choose a reason for hiding this comment

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

Removing all this code from the constructor will break explicit specialization which is used by @_specialize (this constructor is invoked by the EagerSpecializer).

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 should be refactored to use the new methods you added though right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Probably, but explicit and automatic partial specializations have rather different setups. So, please leave this code there for now. I'll re-factor myself once we are there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I'll put it back and add a FIXME.

@slavapestov slavapestov force-pushed the subst-fixes branch 2 times, most recently from 8956e08 to 1c05ae8 Compare April 5, 2017 06:30
@slavapestov
Copy link
Contributor Author

swiftlang/swift-corelibs-foundation#951

@swift-ci Please smoke test Linux

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

Fix an odd corner case when UseErrorTypes was off; we would
return the empty type if dependent member type substitution
failed, but otherwise return the original type if it was a
generic type parameter or an archetype.

Now, if UseErrorTypes is off, return the empty type in both
cases, even if the original type is 'primary'.
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov slavapestov merged commit 34a5e75 into swiftlang:master Apr 18, 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