[CSOptimizer] Add support for opened existential arguments #83735
Conversation
…enExistentialCallArgument` into a separate function Some of the logic of `canOpenExistentialCallArgument` has to be shared with constraint optimizer which does it's own validation and most importantly - doesn't open overload choice type. In order to share the logic between the solver and the optimizer, let's extract checking that determines whether it's possible to open existential argument into `canOpenExistentialAt`.
xedin
requested review from
AnthonyLatsis,
hborla and
slavapestov
as code owners
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
There was a problem hiding this comment.
Is the guard let essential to the test case?
There was a problem hiding this comment.
Yeah, it needs to be unwrapped before passing it to test to make sure that the argument is non-optional and known in advance.
There was a problem hiding this comment.
I should note that today existential opening doesn't work for stuff like env ?? <<default>> because it currently happens in simplifyApplicableFnConstraint and at that point the argument won't be resolved. This is a bug we need to fix.
There was a problem hiding this comment.
ah, the issue is that test() is overloaded, I see!
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
Check whether it would be possible to match a parameter type by opening an existential type of the candidate argument. Resolves: rdar://158159462
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please test Windows platform |
1 similar comment
|
@swift-ci please test Windows platform |
|
@swift-ci please test source compatibility |
|
@swift-ci please smoke test macOS platform |
2 participants
Check whether it would be possible to match a parameter type
by opening an existential type of the candidate argument.
Resolves: rdar://158159462