/cc @rudkx

So I thought of a sneaky way around this if we can’t take the source break: We can re-apply the patch and increase the MAX_SPACE limit to compensate for this case.

We ran into this issue again while testing the swift 5.0 branch. We should revert on master while waiting for the fix!

Alright, so to get at the root of this:

The issue that the just-reverted patch was trying to solve is this rather odd-looking switch-case

func largeSpaceMatch(_ x: Bool) {       
 switch (x, (x, x, x, x), (x, x, x, x)) { // expected-error {{switch must be exhaustive}}       
 // expected-note@-1 {{do you want to add a default clause?}}       
 case (true, (_, _, _, _), (_, true, true, _)):     
   break        
 case (true, (_, _, _, _), (_, _, false, _)):       
   break        
 case (_, (_, true, true, _), (_, _, false, _)):        
   break        
 case (_, (_, _, false, _), (_, true, true, _)):        
   break        
 case (_, (_, true, true, _), (_, true, true, _)):      
   break        
 case (_, (_, _, false, _), (_, _, false, _)):      
   break        
 case (_, (false, false, false, false), (_, _, _, _)):      
   break        
 }      
}

The old check believes (correctly) that the Space of the type

(Bool, (Bool, Bool, Bool), (Bool, Bool, Bool))

has a total of 2^7 = 128 inhabitants. The heuristic, however, also believes (incorrectly) that this switch statement covers more than 128 cases - it therefore assumes it covers all possible cases and admits this code to lower phases where it lowers to a fatal error with no debug info. While not technically a miscompile, this is still an open hole in the semantics of switch statements that I would like to close despite source-breakage of a particular form.

The current issue seems to be that projects with machine-generated switch-statements over enums with many associated values (cf the linked AST) are hitting the revised (and stricter) heuristic and getting rejected as potentially non-exhaustive where before they just happened to slip through because of the old incorrect size-based check. Unfortunately, the ways I can think of correcting the old size-based check would also fail to build the switch-statement in this issue or would potentially put the compiler into a flat-loop in the worst case (which is why we came up with these size heuristics in the first place). I would really appreciate the opportunity to roll back to a more correct-but-conservative semantics first and later expand the capabilities of the check to cover complex enums like this when I have a better plan for how to deal with the combinatorial explosion in the checker - even if it means that we have to ask some projects like this one to insert a default clause or twelve in their switch statements.

I will continue to experiment with ways around this, including restoring the size heuristic in cases where we can prove there really is no pattern overlap.

@CodaFi Are you planning to take a look at this issue in the near future?

#21230