Skip to content

altsAreExhaustive and empty case alternatives

Empty case alternatives in Core are somewhat special; they denote scrutinees that will never return (see Note [Empty case alternatives]).

!10088 (closed) wants to delay lowering of such empty case alternatives in Core from CorePrep to CoreToStg.

Unfortunately, CorePrep also inserts an impossibleError in the presence of -fcatch-nonexhaustive-cases, which currently would also happen for empty case alternatives, because altsAreExhaustive is defined like

altsAreExhaustive :: [Alt b] -> Bool
-- True  <=> the case alternatives are definitely exhaustive
-- False <=> they may or may not be
altsAreExhaustive []
  = False    -- Should not happen
altsAreExhaustive (Alt con1 _ _ : alts)
  = case con1 of
      DEFAULT   -> True
      LitAlt {} -> False
      DataAlt c -> alts `lengthIs` (tyConFamilySize (dataConTyCon c) - 1)
      -- It is possible to have an exhaustive case that does not
      -- enumerate all constructors, notably in a GADT match, but
      -- we behave conservatively here -- I don't think it's important
      -- enough to deserve special treatment

And although it says "should not happen", the empty alts case is triggered in the call site of ok_expr (worker function of exprOkForSpeculiation).

  1. Since it can happen, we should change the comment.
  2. Is False really the correct thing here? It's naught to ask whether an empty case is exhaustive, because it will never return in the first place.
  3. Since this affects insertion of impossibleErrors, it provokes linker errors in !10088 (closed) when such errors are introduced when compiling ghc-bignum. Shouldn't we compile this package with -fno-catch-nonexhaustive-cases?
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information