Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-12131] Keypaths with the wrong base type yield misleading errors #54566

Closed
swift-ci opened this issue Feb 5, 2020 · 5 comments
Closed

[SR-12131] Keypaths with the wrong base type yield misleading errors #54566

swift-ci opened this issue Feb 5, 2020 · 5 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Feb 5, 2020

Previous ID SR-12131
Radar rdar://problem/59216634
Original Reporter juliand665 (JIRA User)
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

Swift 5.1.3
Xcode 11.3 (11C29)

macOS Catalina 10.15.3

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, TypeChecker
Assignee None
Priority Medium

md5: 240a2a33b45480de1db96f07b198f1f1

Issue Description:

Trying to use the `[keyPath:]` subscript with a keypath with an incorrect base type doesn't yield an error telling you that, instead telling you the value has no subscripts (when getting) or that you cannot assign through the subscript because the value is immutable (when setting).

Consider the following snippet:

struct Struct {
    func get(_ member: KeyPath<Struct, Int>) -> Int {
        self[keyPath: member]
    }
    
    mutating func set(_ member: WritableKeyPath<Struct, Int>, to value: Int) {
        self[keyPath: member] = value
    }
    
    func get(_ member: KeyPath<Other, Int>) -> Int {
        self[keyPath: member]
    }
    
    mutating func set(_ member: WritableKeyPath<Other, Int>, to value: Int) {
        self[keyPath: member] = value
    }
}


struct Other {}

The first two methods compile just fine, but the second two yield those misleading errors I mentioned (screenshot attached).
@theblixguy
Copy link
Collaborator

On Swift 5.2 I get:

error: unexpected error produced: cannot convert return expression of type 'Any?' to return type 'Int'
                self[keyPath: member]
                    ^
error: unexpected error produced: cannot assign through subscript: 'self' is immutable
                self[keyPath: member] = value
                    ^

@beccadax
Copy link
Contributor

beccadax commented Feb 6, 2020

@swift-ci create

@LucianoPAlmeida
Copy link
Collaborator

This is fixed on master the new improved message is "Key path with root type 'Other' cannot be applied to a base of type 'Struct'"
juliand665 (JIRA User) Can you please verify using the latest master snapshot and close? Thanks

@swift-ci
Copy link
Collaborator Author

Comment by Julian Dunskus (JIRA)

Looks great! I'm getting "Key path with root type 'Other' cannot be applied to a base of type 'Struct'", which makes perfect sense.

However, and I'm not sure if it's just Xcode causing this (couldn't figure out a way to use the command-line tools from the snapshot), but after a second or so the old errors pop up too, in addition to the new helpful ones.

@swift-ci
Copy link
Collaborator Author

Comment by Julian Dunskus (JIRA)

Never mind; an Xcode restart fixed that. Closing!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@beccadax @theblixguy @LucianoPAlmeida @swift-ci