[CS] Explore additional bindings for fixes #30686
Conversation
|
@swift-ci please test |
|
|
||
| // If this requirement is associated with an overload choice let's | ||
| // tie impact to how many times this requirement type is mentioned. | ||
| if (auto *ODRE = dyn_cast<OverloadedDeclRefExpr>(anchor)) { |
There was a problem hiding this comment.
What do you think about an idea of not considering requirement failures recoverable in reference to operators?
I'm just trying to figure out how to move a needle in situations like:
func sr12438(_ e: Error) {
func foo<T>(_ a: T, _ op: ((T, T) -> Bool)) {}
foo(e, ==) // expected-error {{type of expression is ambiguous without more context}}
}The problem here is that none of the operator declarations for == are going to match and they are all going to fail in different ways. I think we shouldn't try to rank such situations but instead be better at detecting completely hopeless situations...
There was a problem hiding this comment.
Hmm, would that be specifically for unapplied operator references, or for operator references in general? Presumably we'd then emit a generic "operator cannot be applied with X operands" diagnostic?
I guess we could just try to detect the case where we have different possible overloads for an operator in diagnoseAmbiguityWithFixes, each with some kind of fix, and call into diagnoseOperatorAmbiguity (though it may need to be tweaked slightly to handle unapplied operator refs).
There was a problem hiding this comment.
Hmm, would that be specifically for unapplied operator references, or for operator references in general?
In general. I am hoping that improvement is going to be two-fold - fewer operators considered in diagnostics mode and more precise diagnostics when no operator overloads match.
That's what I was thinking as well, the problem is that we need to move diagnoseOperatorAmbiguity before findBestSolution and that could affect some of diagnostics.
There was a problem hiding this comment.
In general. I am hoping that improvement is going to be two-fold - fewer operators considered in diagnostics mode and more precise diagnostics when no operator overloads match.
My only worry is for people defining their own operators that require conformances for arguments, it would be a shame to lose the requirement fixes there, perhaps we should limit it to known stdlib operators? Or maybe operators that have lots of overloads?
There was a problem hiding this comment.
Yeah, maybe that should be limited only to stdlib operator overloads only.
Previously we could skip default literal or supertype bindings if we had already found a solution with fixes, which could lead us to miss bindings that produce better diagnostics. Tweak the logic such that we continue exploring if we're in diagnostic mode. Resolves SR-12399.
We should only be attempting such overloads for nil literal args. Resolves SR-12426.
- In `simplifyConformsToConstraint`, pass the LHS type regardless of whether it is a type variable. - Add the `choiceImpact` onto the impact for adding a stdlib conformance. - Treat Any and AnyObject as standard library types.
hamishknight
force-pushed
the
more-fixed-types
branch
from
5af806d to
b4c13c2
Compare
hamishknight
force-pushed
the
more-fixed-types
branch
from
8d19978 to
b4c13c2
Compare
|
@swift-ci please test |
|
@swift-ci please test Windows |
|
Okay I've opened #30713 to adjust the test case, and filed rdar://61028087. |
Previously we could skip defaultable constraints or supertype bindings if we had already found a solution with fixes, which could lead us to miss bindings that produce better diagnostics.
Tweak the logic such that we continue exploring if the bindings we've attempted so far have all required fixing.
Resolves SR-12399 & SR-12426.