GenericSignatureImpl, #31712: Plug remaining relevant methods with ty… #31927
Conversation
…s with type param. assertions
|
@swift-ci please test macOS |
| @@ -428,7 +428,7 @@ Type GenericSignatureImpl::getSuperclassBound(Type type) const { | |||
| /// required to conform. | |||
| GenericSignature::RequiredProtocols | |||
| GenericSignatureImpl::getRequiredProtocols(Type type) const { | |||
| if (!type->isTypeParameter()) return { }; | |||
| assert(type->isTypeParameter() && "Expected a type parameter"); | |||
There was a problem hiding this comment.
It would also be nice to assert if resolveEquivalenceClass() returns an unresolved type or concrete type, instead of returning an empty array, but I don't know what the fallout from that might be.
There was a problem hiding this comment.
Do you think calling this on a same-type-to-concrete type parameter and getting back an empty array might backfire on us?
There was a problem hiding this comment.
I would expect that any code doing so is already incorrect, because we can't hope to return a consistent result in this case. Should it be empty, or reflect any existing (possibly redundant) conformance constraints?
There was a problem hiding this comment.
I see. There is a similar issue with getSuperclassBound, and others, I guess. For example, in checkTypeWitness, we always want an explicit bound, not one implied by a conformance constraint, to avoid checking both inheritance and conformance (a syntactic conformance, even if it's broken, should always be enough for the candidate to pass).
|
Build failed |
|
@swift-ci please test source compatibility |
|
@swift-ci please clean test |
|
@swift-ci please clean test source compatibility |
|
@swift-ci please test source compatibility |
|
Debug builder failure unrelated |
…pe param. assertions
Follow-up to #31712