[GSB] When adding same-type requirements pick representative based on… #20646
Conversation
|
@swift-ci please test source compatibility |
| unsigned nestingDepth2 = T2->getNestingDepth(); | ||
| if (nestingDepth2 < nestingDepth1) { | ||
| // Pick representative based on the canonical ordering of the type parameters. | ||
| if (compareDependentTypes(depType2, depType1) < 0) { |
There was a problem hiding this comment.
This is a very nice simplification, thank you!
| @@ -48,7 +48,7 @@ extension P2 where Self : P3, T == Int { | |||
| } | |||
|
|
|||
| extension P2 where Self : P3 { | |||
| func takeT1(_: T) {} | |||
| func takeT1(_: T) {} // expected-error {{'T' is ambiguous for type lookup in this context}} | |||
There was a problem hiding this comment.
I feel like we've tripped over this specific bug in a number of places, where unqualified lookup is ambiguous but shouldn't be. I suspect your change isn't making it much worse in practice.
There was a problem hiding this comment.
Sounds good! I'm going to work on other diagnostic...
There was a problem hiding this comment.
I recently did some work to fix (some) of these cases. The extension Foo where Self : Bar looks like yet another one, though...
… canonical order Instead of trying to order based on the "nested depth", let's always prefer canonical ordering of type parameters when it comes to picking representative equivalence class. Resolves: rdar://problem/45957015
|
@DougGregor This patch is ready for you to take another look, I made it so duplicate same-type diagnostics are now produces in source order even if canonical ordering is completely different. |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci please smoke test Linux platform |
Instead of using `std::sort`, transform source-ordered edge vector to reference `IntercomponentEdge *` instead of their indices in `intercomponentEdges` vector and use `llvm::array_pod_sort` to sort them.
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci please test source compatibility |
|
How interesting! This pull request broke the tests I just tried to add for https://bugs.swift.org/browse/SR-8767, which had been fixed on master before that (hence my attempt at merging #20795). I wonder if we were getting lucky, or if there's something deeper that we didn't notice. |
… canonical order
Instead of trying to order based on the "nested depth", let's
always prefer canonical ordering of type parameters when it comes
to picking representative equivalence class.
Resolves: rdar://problem/45957015