Commit Graph

9 Commits

Author SHA1 Message Date
Pavel Yaskevich
8b4985054a [CSDiagnostics] Differentiate between key path type and value issues
Make sure that contextual mismatch uses a correct locator when
the issue is with key path value type instead of the key path
type.
2023-11-01 09:15:14 -07:00
Sam Lazarus
ed3eaef179 Sema / Test: Revert the error for assignment through read-only key path
This updates the error message so that in the case where we can find a
Decl, it gives the error "cannot assign through subscript: 'name' is a
read-only key path", and in the case where there's no associated Decl, gives the
error message "cannot assign through subscript: key path is read-only".

Additionally updates tests with the new error messages and formats all changes.
2019-05-04 14:03:06 -04:00
Sam Lazarus
1a1e77077a Test / Sema: Change the wording of assignment through read-only key path error 2019-05-03 22:16:56 -04:00
Sam Lazarus
cefbb12ed2 Test: Update swift 5 keypath tests to reflect and test new behavior 2019-05-03 22:16:56 -04:00
Pavel Yaskevich
94977ee175 [TypeChecker] Improve contextual mismatch diagnostics for key path
Detect situations where key path doesn't have capability required
by the context e.g. read-only vs. writable, or either root or value
types are incorrect e.g.

```swift
struct S { let foo: Int }
let _: WritableKeyPath<S, Int> = \.foo
```

Here context requires a writable key path but `foo` property is
read-only.
2019-04-26 10:59:01 -07:00
gregomni
821f63fe98 Make assignments and assignment failure diagnoses directly in the CS.
More specific diagnoses for assigning to read-only keypaths.
'computeAssignDestType' is dead code now.
ConstraintFix shouldRecordFix()
2018-08-24 20:39:03 -07:00
Mark Lacey
c62b7eae0d Add keypath write test for -swift-version 5. 2018-06-25 23:38:36 -07:00
Mark Lacey
9687615d58 Fix RUN lines in a couple constraint solver tests. 2018-06-19 12:57:05 -07:00
Mark Lacey
83ebd71644 Allowing forming WritableKeyPath to read-only value in Swift 3/4.
We inadvertantly allowed this in the past, so continue to do so when
compiling in Swift 3/4 mode to avoid suddenly breaking existing code.

The diagnostic here is pretty bad, and I've opened issues for that as
well as providing some kind of deprecation warning for this so that
even under Swift 3/4 mode we alert users that this is unsupported.

rdar://problem/39802797
2018-05-08 14:26:02 -07:00