[4.0] [GSB] Improve handling of concrete types, type aliases, recursion #10596
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 |
NestedTypeUpdate was mostly just the internal name for ArchetypeResolutionKind, but the translation was a bit lossy and there was no point in having separate enums. Standardize on ArchetypeResolutionKind, adding a new case (WellFormed) to capture the idea that we can create a new potential archetype only when we know there is a nested type with that name---and avoid creating unresolved potential archetypes. (cherry picked from commit fafeec0) (cherry picked from commit 05bc0ef)
Rather than abusing the "superclass" requirement source with a null protocol conformance, introduce a separate "structurally derived" requirement source kind for structurally-derived requirements that don't need any additional information, e.g., the class layout requirement derived from a superclass requirement. (cherry picked from commit ffea1b3) (cherry picked from commit 830da21)
Centralize and simplify the handling of conformance requirements resolved by same-type-to-concrete requirements in a few ways: * Always store a ProtocolConformanceRef in via-superclass and via-concrete requirement sources, so we never lose this information. * When concretizing a nested type based on its parent, use the via-concrete conformance information rather than performing lookup again, simplifying this operation considerably and avoiding redundant lookups. * When adding a conformance requirement to a potential archetype that is equivalent to a concrete type, attempt to find and record the conformance. Fixes SR-4295 / rdar://problem/31372308. (cherry picked from commit 52e52b5) (cherry picked from commit 50a7ad5)
…pes. In some circumstances, we could end up growing increasingly-nested potential archetypes due to a poor choice of representatives and anchors. Address this in two places: * Always prefer to use the potential archetype with a lower nesting depth (== number of nested types) to one with a greater nesting depth, so we don't accumulate more nested types onto the already-longer potential archetypes, and * Prefer archetype anchors with a lower nesting depth *except* that we always prefer archetype anchors comprised of a sequence of associated types (i.e., no concrete type declarations), which is important for canonicalization. Fixes SR-4757 / rdar://problem/31912838, as well as a regression involving infinitely-recursive potential archetypes caused by the previous commit. (cherry picked from commit a72a2bf) (cherry picked from commit 398b99a)
When two potential archetypes are merged and only one of them was a concrete type beforehand, concretize the nested types in the equivalence class of the non-concrete potential archetype. Otherwise, we're liable to miss redundancies. This feels like an ad hoc extension to an ad hoc mechanism, but gets us back to parity with this patch series. (cherry picked from commit bf730ff) (cherry picked from commit 8295561)
When we see two type(aliase)s with the same name in a protocol hierarchy, make them equal with an implied same-type requirement. This detects inconstencies in typealiases across different protocols, and eliminates the need for ad hoc consistency checking. This is a step toward simplifying away the need for direct-diagnosis operations involving concrete type mismatches. While here, warn when we see an associated type with the same as a typealias from an inherited protocol; in this case, the associated type is basically useless, because it's going to be equivalent to the typealias. (cherry picked from commit c47aea7) (cherry picked from commit e01e302)
When a concrete requirement is invalid due to the concrete type lacking a conformance to a particular, required protocol, don't emit that incorrect requirement---it causes invalid states further down the line. Fixes SR-5014 / rdar://problem/32402482. While here, fix a comment that Huon noticed trailed off into oblivion. (cherry picked from commit dd38697) (cherry picked from commit e1395ea)
Fixes two more recently-found GSB crashers. (cherry picked from commit 19f4ee7)
DougGregor
force-pushed
the
gsb-concrete-types-recursion-4b3
branch
from
cda8e58 to
c9a648c
Compare
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
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.
Explanation: Improves our handling of concrete conformances, type aliases in protocols, and same-type-to-concrete constraints in the generic signature builder to make them all more consistent and robust.
Scope: Affects many uses of generic code; will reject a number of ill-formed cases that would previously crash the compiler.
Radar: SR-4295 / rdar://problem/31372308, SR-4757 / rdar://problem/31912838, SR-4786 / rdar://problem/31955862, SR-5014 / rdar://problem/32402482, SR-4737 / rdar://problem/31905232, plus a few other dupes.
Risk: Low-ish. The generic signature builder is key to all generics handling in Swift, so changes there can cause breakage... but it's also fairly well-tested via the standard library, so it's likely we'd have caught regressions.
Testing: Compiler regression testing, plus lots of new tests from the various fixed radars.