Update SK_LastScoreKind to SK_KeyPathSubscript. #9996
Conversation
When this score kind was added, the marker for the last score kind was
not updated. As a result, increasing the score for SK_KeyPathSubscript
was not actually having an effect.
Add tests that include a type with subscripts that also take the key
paths as their argument with an identical argument label ("keyPath").
These tests show that we're actually falling back on the keypath
application in many cases despite the score kind specific to keypath
application. I'll open a couple new JIRAs to investigate this
behavior.
The update to SK_LastScoreKind results in fixing a crash in these tests
that happens as a result of an assumption in CSRanking.cpp that if we're
comparing two solutions we end up with decls for overloads to compare,
which isn't the case here due to the keypath application.
|
@swift-ci Please smoke test |
|
@jckarter FYI: I opened https://bugs.swift.org/browse/SR-5052 and https://bugs.swift.org/browse/SR-5053 for the issues I noticed here. If my assumptions about what should be happening here as noted in the test is wrong, let me know! |
| subscript(keyPath: KeyPath<ZwithSubscript, Int>) -> Int { return 0 } | ||
| subscript(keyPath: WritableKeyPath<ZwithSubscript, Int>) -> Int { return 0 } | ||
| subscript(keyPath: ReferenceWritableKeyPath<ZwithSubscript, Int>) -> Int { return 0 } | ||
| subscript(keyPath: PartialKeyPath<ZwithSubscript>) -> Any { return 0 } |
There was a problem hiding this comment.
Subscripts don't have significant labeled arguments unless you explicitly ask for them, so all of these declarations really declare subscript(_:). You'd have to declare subscript(keyPath kp: ...) to test overloading.
|
Oh yes, thanks for pointing that out. I updated the tests to add the labeled argument and updated the output accordingly. #10001 It's still unfortunate that for subscripts with only getters we fall back on the key path application when attempting to do an assignment. |
|
Yeah, I suspect that's fallout from us modeling |
When this score kind was added, the marker for the last score kind was
not updated. As a result, increasing the score for SK_KeyPathSubscript
was not actually having an effect.
Add tests that include a type with subscripts that also take the key
paths as their argument with an identical argument label ("keyPath").
These tests show that we're actually falling back on the keypath
application in many cases despite the score kind specific to keypath
application. I'll open a couple new JIRAs to investigate this
behavior.
The update to SK_LastScoreKind results in fixing a crash in these tests
that happens as a result of an assumption in CSRanking.cpp that if we're
comparing two solutions we end up with decls for overloads to compare,
which isn't the case here due to the keypath application.