Comment by Ding Ye (JIRA)

It is actually not as simple as it appears. Two occurrences of "NWError" is the culprit.

NWConnection.State takes 223 spaces, where either of ".waiting(: NWError)" and ".failed(: NWError)" occupies 109 spaces. This is because the subcase ".posix(_: POSIXErrorCode)" takes 106 spaces.

Such a large space size exceeds the MAX_SPACE_SIZE (i.e., 128), and consequently triggers "diagnoseCannotCheck()".

It's not immediately clear to me why the associated values are entering into exhaustion checking for a switch with no where clauses. All we do with the associated variables is bind them to a variable, all we need to do is check that each case appears, there should be a fast path for this scenario

Separately I think this enum is poorly designed for the application, these two cases can be combined and I will be lobbying the author to do so. IMO we should support bad designs though

Nice analysis, Ding. And Drew is right: estimating the full space is overkill when most people probably won't match into the payload. cc CodaFi (JIRA User), @xedin, me

We've run into a similar issue in swift-protobuf against the Swift 5.1 compiler. Our conformance tests generate some enums with a pretty huge number of cases, so perhaps we're doing this to ourselves in a way, but this particular example compiled without error in Swift 5.0:

https://github.com/apple/swift-protobuf/blob/e4cb49ed5d10b387dd50d6ab387b6c45c9a74c5c/Tests/SwiftProtobufTests/generated_swift_names_enum_cases.pb.swift#L1749

That enum has 853 cases with no payloads and 1 case with an Int32 payload. However, with some local testing, it looks like we have the same issue if we remove the UNRECOGNIZED case and just have a simple enum with a large number of cases.

We can work around it by tweaking our generator to partition the switch into "buckets" each with a default clause, but we imagine that this will incur some codegen cost (at a minimum, a final default clause with a fatalError that the compiler can't determine is actually unreachable). The concern there is that we always pick the right "magic number" for the bucket size that will make the compiler happy from version to version.

Are there any other options here, aside from "don't generate huge enums"?

Since Drew's original case now works, it may be better to file a new bug here.

Done. https://bugs.swift.org/browse/SR-11533