[GenericSig Builder] Track and canonicalize same-type-to-concrete constraints #7518
Conversation
|
@swift-ci please smoke test and merge |
|
@swift-ci please smoke test |
|
Oh, requirement sources. Right. |
… checks." This reverts commit 58f181a.
… archetype anchor." This reverts commit 0df3adb.
…straints. Track each same-type-to-concrete constraint on the potential archetype against which it was written, and ensure that the requirement sources for such same-type constraints stay with the potential archetypes on which they were described. This is similar to the way we track same-type constraints among potential archetypes. Use this information to canonicalize same-type-to-concrete constraints appropriately. For each connected component within an equivalence class of potential archetypes, select the best requirement source to the concrete type, or substitute in an abstract requirement source if none exists. This approach ensures that components that would be equivalent to that concrete type anyway get a derived source, while components that get the concrete-type equivalence by being tied to another To get here, we also needed to change the notion of the archetype anchor so that potential archetypes with no same-type constraints directly in their path are preferred over potential archetypes that do have a same-type constraint in their path. Otherwise, the anchor might be something that is always concrete and is, therefore, not terribly interesting. Fixes the new case that popped up in rdar://problem/30478915.
`GenericSignatureBuilder::resolve()` was always jumping to the representative, to treat typealias representatives as special. However, doing this means that we put the same-type constraint on the wrong potential archetype (with the wrong source). Eliminate the use of `getRepresentative()`. This unfortunately causes us to need recursive resolution, because we can't always depend on jumping to the representative to avoid it.
DougGregor
force-pushed
the
concrete-archetype-anchors
branch
from
65997d6 to
10fc3fa
Compare
DougGregor
changed the title
|
@huonw the non-recursive resolution in the new |
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
|
Interesting failure on Linux: |
|
@swift-ci please test OS X |
|
Build failed |
|
@DougGregor You have a type that appears in getAllDependentTypes(), but maps to a concrete type... this isn't supposed to happen. |
|
@swift-ci please smoke test Linux |
I think switching it to be recursive should be fine: the only reason it wasn't was that it didn't need to be at the time. |
|
Okay. I actually hope we can avoid the recursion, because in destroying type sugar we lose some information that I don't want to lose, but it Needs More Thought. |
… map. It turns out that GenericSignature::getAllDependentTypes() sometimes includes generic type parameter types that have been made concrete. Tolerate this for now, because fixing it causes issues elsewhere.
|
@swift-ci please smoke test and merge |
1 similar comment
|
@swift-ci please smoke test and merge |
|
@slavapestov, I weakened the assert. But I still want to look into the generic parameters that are ending up concrete but are still in getAllDepwndentTypes |
|
@DougGregor Very nice! Could you also try to fix rdar://30610428? This is the next blocker for the partial specialization. |
Track each same-type-to-concrete constraint on the potential archetype
against which it was written, and ensure that the requirement sources
for such same-type constraints stay with the potential archetypes on
which they were described. This is similar to the way we track
same-type constraints among potential archetypes.
Use this information to canonicalize same-type-to-concrete constraints
appropriately. For each connected component within an equivalence
class of potential archetypes, select the best requirement source to
the concrete type, or substitute in an abstract requirement source if
none exists. This approach ensures that components that would be
equivalent to that concrete type anyway get a derived source, while
components that get the concrete-type equivalence by being tied to
another component end up with (abstract) explicit requirements to the concrete type.
To get here, we also needed to change the notion of the archetype
anchor so that potential archetypes with no same-type constraints
directly in their path are preferred over potential archetypes that do
have a same-type constraint in their path. Otherwise, the anchor might
be something that is always concrete and is, therefore, not terribly
interesting.
Fixes the new case that popped up in rdar://problem/30478915.