[NCGenerics] fold InverseType into PCT #70278
Conversation
kavon
requested review from
ahoppen,
bnbarham,
CodaFi,
DougGregor,
rintaro,
AnthonyLatsis,
hborla,
slavapestov,
xedin,
adrian-prantl,
zoecarver,
hyp,
egorzhdan and
tshortli
as code owners
|
@swift-ci please smoke test |
|
@swift-ci please smoke test macOS platform |
kavon
force-pushed
the
refactor-InverseType
branch
from
949a7d7 to
d4842f2
Compare
|
@swift-ci please smoke test linux platform |
|
|
||
| // At this point, we have a conformance constraint with an inverse. | ||
| auto subject = req.getFirstType()->getCanonicalType(); | ||
| // WARNING: possible quadratic behavior, but should be OK in practice. |
There was a problem hiding this comment.
This could check getDepth()
| SmallVector<Type, 4> localGPs; | ||
| if (genericParamList) | ||
| for (auto *gtpd : genericParamList->getParams()) | ||
| localGPs.push_back(gtpd->getDeclaredInterfaceType()); |
There was a problem hiding this comment.
localGPs could be replaced with a depth check
| @@ -447,8 +447,12 @@ RequirementSignatureRequest::evaluate(Evaluator &evaluator, | |||
| } | |||
| } | |||
|
|
|||
| // FIXME: We don't have the inverses from desugaring available here! | |||
There was a problem hiding this comment.
StructuralRequirementsRequest could return a second list of inverses as part of the request result
| diag::noncopyable_generic_but_copyable, | ||
| proto->getSelfInterfaceType(), | ||
| getProtocolName(KnownProtocolKind::Copyable)); | ||
| continue; |
There was a problem hiding this comment.
Why isn't this diagnosed in diagnoseRequirementErrors() along with the other cases?
There was a problem hiding this comment.
I think it's because the StructuralRequirementsRequest isn't carrying the InverseRequirements up to RequirementSignatureRequest. I'll try your suggestion and see if that makes this bit of code redundant.
There was a problem hiding this comment.
Tried it and got a verification failure in the requirement machine. Will have to dig into it later.
kavon
force-pushed
the
refactor-InverseType
branch
from
d4842f2 to
23533f7
Compare
|
@swift-ci please test |
We already need to track the inverses separate from the members in a ProtocolCompositionType, since inverses aren't real types. Thus, the only purpose being served by InverseType is to be eliminated by RequirementLowering when it appears in a conformance requirement. Instead, we introduce separate type InverseRequirement just to keep track of which inverses we encounter to facilitate cancelling-out defaults and ensuring that the inverses are respected after running the RequirementMachine.
kavon
force-pushed
the
refactor-InverseType
branch
from
23533f7 to
63b3e76
Compare
|
@swift-ci please test |
We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.