[SR-3652] Enum with associated type with same protocol conformance make the code crash at runtime

[swift-ci]

Previous ID	SR-3652
Radar	None
Original Reporter	dalu93 (JIRA User)
Type	Bug

Environment

Xcode Version 8.2.1 (8C1002) - Swift included in Xcode (no development version)

Additional Detail from JIRA

| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug, RunTimeCrash | |Assignee | None | |Priority | Medium | md5: d08637b4581d6bf40f0bc3516e0f5fb3

Issue Description:

Hi,
Please, skip the logical part of the code and the decision why it is written as it is.

I have one protocol called Expression

protocol Expression {
    var key: String { get }
    var name: String { get }
}

My two structs Mood and Theme conform to this protocol.
Now I have an enum like below

enum DataItem {
    case dataItemMood(Mood)
    case dataItemTheme(Theme)
    case dataItemBanner(Banner)
    case dataItemClip(Clip)
}

When actually I want to check whether the item I have is an Expression item, I check it in this way

switch item {
            case .dataItemMood(let category as Expression), .dataItemTheme(let category as Expression):
                if selectedCategory.key == category.key { return index }

            default: break
            }

This seems to make totally sense to the compiler (it compiles without any problem, and it makes sense actually because I'm treating the associated type as same type), but it crashes at runtime.

[belkadan]

@gregomni, are you still looking at these "compound switch case" issues? If not, @jckarter, who should take this?

[belkadan]

(This may also be fixed in master; I didn't check.)

[jckarter]

I don't believe it is fixed. If @atrick gets far enough along with SSA generics, that would obviate the need for a fix here.

[gregomni]

Unfortunately, it's been quite a while since I've been able to give this project any significant time, so if someone else is able to take it on, that would probably be for the best. Sorry!

[gregomni]

Yeah, it does seem as if Andrew Trick's plan would necessarily❓ remove the distinction between the "normal" enum_unchecked_data and the unchecked_take_enum_data_addr that is what makes this problem difficult. At least it would move the issue down lower where the solution would be more general and hopefully easier.