[GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code

[GHC]

#10600: -fwarn-incomplete-patterns doesn't work with -fno-code
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  ezyang
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  7.10.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect         |  Unknown/Multiple
  warning at compile-time            |            Test Case:  driver/T8101b
      Blocked By:                    |             Blocking:
 Related Tickets:  #8101             |  Differential Rev(s):  Phab:D1278
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by duog):

 Replying to [comment:23 mpickering]:
 > Is there a conceptual problem of moving the pattern match checker to the
 end of typechecking? There is the additional fiddlyness to make sure all
 pattern occurrences are checked but this seems preferable than making
 `-fno-code` slower for everyone.

 I'm not qualified to answer that, but it's a bigger problem than just
 pattern match checking(Maybe we should change the ticket name?). The whole
 point of -fno-code is to check code for errors and warnings, and many
 errors and warnings are currently thrown by the desugarer.

 I would expect that correctness is the most important concern, and that a
 slower, more correct -fno-code is preferable. I also expect that
 desugaring is in general a much less expensive operation than
 typechecking. Please correct me if I'm wrong!

 Below I give a rough enumeration of the warnings and errors that the
 desugarer can currently throw, and some ideas about how to proceed.

 The warnings listed in D1278 (comment 12, 20 months ago) as throwable by
 the desugarer are:
 * Opt_WarnIncompletePatterns (-W)
 * Opt_WarnIncompleteUniPatterns
 * Opt_WarnIncompletePatternsRecUpd
 * Opt_WarnIdentities
 * Opt_WarnOverflowedLiterals (def)
 * Opt_WarnEmptyEnumerations (def)
 * Opt_WarnInlineRuleShadowing (def)
 * Opt_WarnOverlappingPatterns (def)
 * Opt_WarnUnusedDoBind (-Wall)
 * Opt_WarnWrongDoBind (def)

 I haven't verified that this list is up to date. I have noted in brackets
 default warnings (def), -W warnings and -Wall warnings.

 The errors throwable by desugaring are a bit hard to find. Grepping and
 chasing errDs, I can see at least:
 * "A levity-polymorphic type is not allowed here:" : DsMonad.dsNoLevPoly
 * "Malformed constructor signature" : updateGadtResult called by
 DsMeta.repC
 * "Top level bindings for unlifted types" : DsBinds.dsTopLevelBinds
 * "Top level strict pattern bindings" : DsBinds.dsTopLevelBinds
 * "You can't mix polymorphic and unlifted bindings:" : DsExpr.ds_val_bind
 * "Recursive bindings for unlifted types aren't allowed:" :
 DsExpr.ds_val_bind
 * "Cannot use primitive with levity-polymorphic arguments:" :
 DsExpr.levPolyPrimopErr
 * "A lazy (~) pattern cannot bind variables of unlifted type." :
 Match.tidy1

 Perhaps there is a list of extensions, where if none were enabled then
 some or all of these errors could be excluded? Say
 * TypeInType
 * MagicHash
 * UnboxedTuples
 * UnboxedSums
 * GADTs
 * BangPatterns
 One would have to think carefully and understand this better than I do.

 Then the first, easiest, solution is to unconditionally desugar with -fno-
 code. This has no maintenance burden and is easy to verify for
 correctness. D3542 implements this.

 Then next improvement could be reducing the work done by the desugarer in
 -fno-code, I intend to look at this.

 Finally one could implement a predicate to determine whether desugaring
 could produce warnings and errors, for example by checking enabled
 warnings and extensions, and desugar only when necessary. One could
 potentially move warnings/errors from desugaring to typechecking to
 facilitate this. This seems like a bit of a maintenance nightmare, but
 maybe it's not even so difficult to get them all out? Or at least
 everything except the TypeInType stuff.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10600#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler