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.

Sign up for GitHub

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-12095] Compiler emits incorrect diagnostics when type matching implicitly castable Errors #3274

Open
robinkunde opened this issue Jan 28, 2020 · 3 comments
Open

[SR-12095] Compiler emits incorrect diagnostics when type matching implicitly castable Errors #3274

robinkunde opened this issue Jan 28, 2020 · 3 comments
Labels
bug Compiler Foundation Standard Library

Comments

@robinkunde
Copy link

Previous ID SR-12095
Radar rdar://problem/58999120
Original Reporter @robinkunde
Type Bug
Environment

Swift 5.1.3

Additional Detail from JIRA
Votes 0
Component/s Compiler, Foundation, Standard Library
Labels Bug
Assignee None
Priority Medium

md5: 0e269daa78868ba77486d440d86397a4

Issue Description:

Importing Foundation makes it so all instances of Error become implicitly castable to CustomStringConvertible by way of converting to NSError first. Explicitly checking if an instance conforms to CustomStringConvertible fails as expected though if the original type doesn't conform. However, the compiler emits an incorrect diagnostics stating that such tests will always succeed.

import Foundation

enum NonConfirmingError: Error {
    case blah
}

let nonConformingError: Error = NonConfirmingError.blah

if case let castError as CustomStringConvertible = nonConformingError { // warning: 'if' condition is always true
    print(castError) // will not be executed
}

if nonConformingError is CustomStringConvertible { // warning: 'if' condition is always true
    print(nonConformingError) // will not be executed
}
@beccadax
Copy link
Contributor

@swift-ci create

@tbkka
Copy link
Contributor

tbkka commented Feb 3, 2020

Robin: I'm curious how you stumbled across this. We don't expect folks to use `CustomStringConvertible` directly, so I'm curious whether you have a real need for that or whether you encountered this with some other protocol?

@robinkunde
Copy link
Author

@tbkka IIRC, I was doing some spelunking to figure out how the string representation of Decodable errors is generated and how implicit bridging to NSError works. Stumbled across some code like this either in the standard library or the corelibs foundation. I noticed the odd behavior while using it in a playground.

I added some conformances to CustomStringConvertable to some types to generate better human-readable error messages, but I don't use any code like the above. Does that help?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Compiler Foundation Standard Library
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@beccadax @robinkunde @tbkka