Cleanup mapType{Into,OutOf}Context() #3252
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci Please test |
Name lookup won't even find typealiases in protocols or protocol extensions in some cases, but it does if the type is referenced from expression context, which exposed a crash. Fix the crash by generalizing the logic a bit. This will be more generally useful once I fix a few more issues in name lookup.
…fTypeInContext() more, NFC There are many places where we do the 'if inside a protocol, get the Self type parameter, otherwise, use the declared type' dance. We actually have really handy utility methods that encapsulate this, so let's use them more.
First, enforce that the superclass of a class is an interface type. Previously, Swift classes used interface types but imported Objective-C generics used archetypes. When the superclass type is always an interface type, we can use the recently-added gatherAllSubstitutions() instead of rolling our own parent type walk. Also, this exposed an issue in name lookup where we would call getSuperclass() on a type whose parent was an unbound generic. This doesn't make sense, so generalize the existing check there.
Before we would construct types containing a mix of interface and contextual types, and then map them in and out. Straighten this out. Note that I've also had to start untangling the issue where synthesized ParamDecls do not have an interface type.
The code in recordTypeWitness() seemed to be completely bogus; it already receives a type written in terms of the archetypes of the adoptee's context, so mapTypeOutOfContext() did nothing here, because it was using the wrong substitutions. The logic for synthesizing designated initializers was also slightly wrong if the class was nested inside a generic function. Finally, interface and contextual types of a derived rawValue were flipped around.
… wrong sort of type Also, bail out earlier if we know we have no work to do.
slavapestov
force-pushed
the
cleanup-map-type-in-and-out-of-context
branch
from
073196f to
f038281
Compare
|
@swift-ci Please test and merge |
slavapestov
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal here is to ensure we don't call mapTypeIntoContext() on a type already containing archetypes, or mapTypeOutOfContext() on a type already containing interface types.
Also, start cleaning up synthesized ParamDecls to have both an interface type and a contextual type, and simplify some ClangImporter logic for Objective-C generics in the process.
Still not done because some compiler_crashers regress.