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
#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]: 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