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

[robinkunde]

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]

@swift-ci create

[tbkka]

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]

@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?