summaryrefslogtreecommitdiff
path: root/docs/users_guide/using-warnings.rst
Commit message (Collapse)AuthorAgeFilesLines
* Add back documentation for deprecated -Whi-shadowingLuke Lau2019-10-271-0/+17
| | | | | | This was removed in b538476be3706264620c072e6e436debf9e0d3e4, but without it the compare-flags.py script fails. This adds it back and marks it as deprecated, with a notice that it is slated for removal.
* users-guide: Fix :since: for -Wunused-packagesBen Gamari2019-10-231-1/+1
| | | | Fixes #17382.
* users-guide: Fix various warningsBen Gamari2019-10-081-9/+27
|
* users-guide: Refer to language extension flags via :extension:Ben Gamari2019-10-081-8/+8
| | | | Previously several were referred to via :ghc-flag:`-X...`.
* Deprecate -fwarn-hi-shadowing, because it was never implemented and isDaroc Alden2019-10-041-13/+0
| | | | | | not used. This fixes #10913.
* PmCheck: Elaborate what 'model' means in the user guide [skip ci]Sebastian Graf2019-09-271-8/+14
|
* PmCheck: Only ever check constantly many models against a single patternSebastian Graf2019-09-251-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Introduces a new flag `-fmax-pmcheck-deltas` to achieve that. Deprecates the old `-fmax-pmcheck-iter` mechanism in favor of this new flag. From the user's guide: Pattern match checking can be exponential in some cases. This limit makes sure we scale polynomially in the number of patterns, by forgetting refined information gained from a partially successful match. For example, when matching `x` against `Just 4`, we split each incoming matching model into two sub-models: One where `x` is not `Nothing` and one where `x` is `Just y` but `y` is not `4`. When the number of incoming models exceeds the limit, we continue checking the next clause with the original, unrefined model. This also retires the incredibly hard to understand "maximum number of refinements" mechanism, because the current mechanism is more general and should catch the same exponential cases like PrelRules at the same time. ------------------------- Metric Decrease: T11822 -------------------------
* Add -Wderiving-defaults (#15839)Kari Pahula2019-09-251-0/+18
| | | | | | Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause a warning when no explicit deriving strategy is in use. This change adds an enable/suppress flag for it.
* Warn about unused packagesYuras Shumovich2019-06-111-0/+15
| | | | | | | | | | | | Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: hvr, simonpj, mpickering, rwbarton, carter GHC Trac Issues: #15838 Differential Revision: https://phabricator.haskell.org/D5285
* Minor spelling fixes to users guide.P.C. Shyamshankar2019-05-291-1/+1
|
* users-guide: Fix directive errors on 8.10Takenobu Tani2019-05-211-2/+4
| | | | | | | | | | | The following sections are not displayed due to a directive error: * -Wunused-record-wildcards * -Wredundant-record-wildcards I changed the location of the `since` directive. [skip ci]
* users-guide: Fix typoNathan Collins2019-04-031-1/+1
|
* Treat kind/type variables identically, demolish FKTVVladislav Zavialov2019-02-271-53/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error.
* Implement -Wredundant-record-wildcards and -Wunused-record-wildcardsMatthew Pickering2019-02-141-3/+47
| | | | | | | | | -Wredundant-record-wildcards warns when a .. pattern binds no variables. -Wunused-record-wildcards warns when none of the variables bound by a .. pattern are used. These flags are enabled by `-Wall`.
* Add -Wmissing-deriving-strategieschessai2019-01-061-0/+21
| | | | | | | | | | | | | | | Warn users when -XDerivingStrategies is enabled but not used, at each potential use site. add -Wmissing-deriving-strategies Reviewers: bgamari, RyanGlScott Subscribers: andrewthad, rwbarton, carter GHC Trac Issues: #15798 Differential Revision: https://phabricator.haskell.org/D5451
* RTS linker: don't crash early when not finding extra-librariesKyrill Briantsev2018-12-111-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow GHCi to not crash when no assumed DLL is found in the standard location. E.g. when loading the package built "dyn" way, we may well have the package's DLL around, and it's the system linker which loads necessary dependencies. Why does this (partially) fix #11042? It's because we often (and when having packages built `dyn` way -- almost always) don't need to load anything recorded in the `extra-libraries` stanza, since if the package DLL exists, GHCi linker simply calls the system linker (via `dlopen`/ `LoadLibrary` APIs) to load it and doesn't bother to load package prelinked object file (if any) or package static library. Thus, all "regular" (with no fancy low-level package content manipulation) packages built "dyn" way should be OK after this fix. Reviewers: hvr, bgamari, int-index Reviewed By: bgamari, int-index Subscribers: Phyx, int-index, rwbarton, carter GHC Trac Issues: #11042 Differential Revision: https://phabricator.haskell.org/D5170
* Improve documentation for warning optionsNathan Collins2018-10-291-4/+11
| | | | | | | | | | | | | My main goal was to make it easy to discover how to reverse `-Werror`, since `Wno-error` doesn't work, and the fact that `-Wwarn` negates `-Werror` was only mentioned in the `-Wwarn` docs before. Other changes: - explain at the outset that some options control individual warnings while others control warning families. - explain at the outset that `-Wno-<wflag>` can be used to reverse `-W<wflag>`. This is no mentioned in two places, but I don't think that's a bad thing.
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-271-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the user to explicitly bind type/kind variables in type and data family instances (including associated instances), closed type family equations, and RULES pragmas. Follows the specification of GHC Proposal 0007, also fixes #2600. Advised by Richard Eisenberg. This modifies the Template Haskell AST -- old code may break! Other Changes: - convert HsRule to a record - make rnHsSigWcType more general - add repMaybe to DsMeta Includes submodule update for Haddock. Test Plan: validate Reviewers: goldfire, bgamari, alanz Subscribers: simonpj, RyanGlScott, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #2600, #14268 Differential Revision: https://phabricator.haskell.org/D4894
* Surprising error message with bang patternSasa Bogicevic2018-10-151-0/+7
| | | | | | | | | | | | Reviewers: bgamari, alanz Reviewed By: bgamari Subscribers: sgraf, mpickering, rwbarton, thomie, carter GHC Trac Issues: #13600 Differential Revision: https://phabricator.haskell.org/D5040
* Include -fwarn-star-is-type in -WcompatVladislav Zavialov2018-10-121-0/+4
| | | | | | | | | | | | | | | | | According to the deprecation schedule in the accepted proposal, the first step is to include `-fwarn-star-is-type` in `-Wcompat`. Test Plan: Validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15476 Differential Revision: https://phabricator.haskell.org/D5044
* Add -Wstar-is-type to the User's GuideVladislav Zavialov2018-10-041-0/+19
| | | | | | | | | | | | | | | The -Wstar-is-type flag was added without documentation. Now it has documentation. Test Plan: Validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5203
* users guide: Fix a few issuesFrank Steffahn2018-09-201-2/+5
|
* Fix typos in -Wsimplifiable-class-constraints flag docsSergey Vinokurov2018-09-041-2/+2
|
* [docs] Add missed specialisations warnings to list of those not enabled by -WallMaximilian Tagher2018-08-061-0/+2
| | | | | | Enabling `-Weverything` does enable those warnings. (cherry picked from commit b062bd10a88ea407ae91610f822f0c352909bcce)
* Do not imply NoStarIsType by TypeOperators/TypeInTypeVladislav Zavialov2018-07-161-0/+31
| | | | | | | | | | | | | | | | | | | | | | Implementation of the "Embrace TypeInType" proposal was done according to the spec, which specified that TypeOperators must imply NoStarIsType. This implication was meant to prevent breakage and to be removed in 2 releases. However, compiling head.hackage has shown that this implication only magnified the breakage, so there is no reason to have it in the first place. To remain in compliance with the three-release policy, we add a workaround to define the (*) type operator even when -XStarIsType is on. Test Plan: ./validate Reviewers: bgamari, RyanGlScott, goldfire, phadej, hvr Reviewed By: bgamari, RyanGlScott Subscribers: harpocrates, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4865
* Remove -Wamp flagroland2018-06-221-16/+0
| | | | | | | | | | | | | | Test Plan: "ghc -Wamp XXX.hs" should give "unrecognised warning flag" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11477 Differential Revision: https://phabricator.haskell.org/D4785
* Add -Werror=compatVladislav Zavialov2018-06-171-0/+6
| | | | | | | | | | | | | | | | | | Add a flag `-Werror=compat` to GHC which has the effect of `-Werror=x -Werror=y ...`, where `x, y, ...` are warnings from the `-Wcompat` option group. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15278 Differential Revision: https://phabricator.haskell.org/D4860
* Warn about implicit kind variables with -WcompatVladislav Zavialov2018-06-161-0/+53
| | | | | | | | | | | | | | | | | | | | | | | According to an accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 4-no-kind-vars.rst With -Wcompat, warn if a kind variable is brought into scope implicitly in a type with an explicit forall. This applies to type signatures and to other contexts that allow a forall with the forall-or-nothing rule in effect (for example, class instances). Test Plan: Validate Reviewers: goldfire, hvr, bgamari, RyanGlScott Reviewed By: goldfire Subscribers: RyanGlScott, rwbarton, thomie, carter GHC Trac Issues: #15264 Differential Revision: https://phabricator.haskell.org/D4834
* Turn "inaccessible code" error into a warningTobias Dammers2018-06-021-1/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With GADTs, it is possible to write programs such that the type constraints make some code branches inaccessible. Take, for example, the following program :: {-# LANGUAGE GADTs #-} data Foo a where Foo1 :: Foo Char Foo2 :: Foo Int data TyEquality a b where Refl :: TyEquality a a checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u) checkTEQ x y = error "unimportant" step2 :: Bool step2 = case checkTEQ Foo1 Foo2 of Just Refl -> True -- Inaccessible code Nothing -> False Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1` and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl` constructor essentially mandates `t ~ u`, and thus `Char ~ Int`. Previously, GHC would reject such programs entirely; however, in practice this is too harsh. Accepting such code does little harm, since attempting to use the "impossible" code will still produce errors down the chain, while rejecting it means we cannot legally write or generate such code at all. Hence, we turn the error into a warning, and provide `-Winaccessible-code` to control GHC's behavior upon encountering this situation. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11066 Differential Revision: https://phabricator.haskell.org/D4744
* document: fix trac issue #14229Võ Anh Duy2018-03-251-2/+2
| | | | | | | | | | | | | | | Accroding to https://git.haskell.org/ghc.git/commitdiff/49672659113371c3bee691e6d913d f8e6f60a1d8, `-Wredundant-constraints` is no longer turn on by default. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4528
* Remove outdated documentation bits concerning -Wmissing-methodsRyan Scott2018-03-081-12/+0
| | | | | | | | | | | | | | | | | | | In commit 503219e3e1667ac39607021b2d9586260fbab32b, we stopped suppressing `-Wmissing-methods` warnings on class methods whose names begin with an underscore. However, it seems the users' guide documentation concerning this was never updated. Let's do so. Test Plan: Read it Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #12959 Differential Revision: https://phabricator.haskell.org/D4476
* Flag `-fdefer-typed-holes` also implies `-fdefer-out-of-scope-variables`.HE, Tao2018-02-021-1/+1
| | | | | | | | | | Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4361
* users-guide: Fix markupBen Gamari2018-01-021-4/+4
|
* Add warn-missing-export-listsEvan Rutledge Borden2017-11-211-0/+26
| | | | | | | | | | | | | | | | | | | | | | | Many industrial users have aligned around the idea that implicit exports are an anti-pattern. They lead to namespace pollution and byzantine naming schemes. They also prevent GHC's dead code analysis and create more obstacles to optimization. This warning allows teams/projects to warn on or enforce via -Werror explicit export lists. This warning also serves as a complement to warn-missing-import-lists. This was originally discussed here: https://github.com/ghc-proposals/ghc-proposals/pull/93 Test Plan: Three new minimal tests have been added to the type checker. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4197
* minor wordsmithingGabor Greif2017-10-301-5/+5
|
* Implement `-Wpartial-fields` warning (#7169)Daishi Nakajima2017-10-251-1/+18
| | | | | | | | | | | | | | | | | Warning on declaring a partial record selector. However, disable warn with field names that start with underscore. Test Plan: Added 1 test case. Reviewers: austin, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: goldfire, simonpj, duog, rwbarton, thomie GHC Trac Issues: #7169 Differential Revision: https://phabricator.haskell.org/D4083
* users-guide: Fix various warningsBen Gamari2017-10-161-1/+1
| | | | [skip ci]
* user-guide: Document -WeverythingBen Gamari2017-09-301-0/+7
| | | | | | | | | | | | | | [skip ci] Reviewers: hvr, austin, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie GHC Trac Issues: #14284 Differential Revision: https://phabricator.haskell.org/D4043
* users_guide: Convert mkUserGuidePart generation to a Sphinx extensionPatrick Dougherty2017-08-181-24/+408
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes all dependencies the users guide had on `mkUserGuidePart`. The generation of the flag reference table and the various pieces of the man page is now entirely contained within the Spinx extension `flags.py`. You can see the man page generation on the orphan page https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghc.html The extension works by collecting all of the meta-data attached to the `ghc-flag` directives and then formatting and displaying it at `flag-print` directives. There is a single printing directive that can be customized with two options, what format to display (table, list, or block of flags) and an optional category to limit the output to (verbosity, warnings, codegen, etc.). New display formats can be added by creating a function `generate_flag_xxx` (where `xxx` is a description of the format) which takes a list of flags and a category and returns a new `xxx`. Then just add a reference in the dispatch table `handlers`. That display can now be run by passing `:type: xxx` to the `flag-print` directive. `flags.py` contains two maps of settings that can be adjusted. The first is a canonical list of flag categories, and the second sets default categories for files. The only functionality that Sphinx could not replace was the `what_glasgow_exts_does.gen.rst` file. `mkUserGuidePart` actually just reads the list of flags from `compiler/main/DynFlags.hs` which Sphinx cannot do. As the flag is deprecated, I added the list as a static file which can be updated manually. Additionally, this patch updates every single documented flag with the data from `mkUserGuidePart` to generate the reference table. Fixes #11654 and, incidentally, #12155. Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11654, #12155 Differential Revision: https://phabricator.haskell.org/D3839
* Fix more documentation wibblesBen Gamari2017-07-231-4/+9
| | | | Fixes #14020, #14016, #14015, #14019
* users-guide: Standardize and repair all flag referencesPatrick Dougherty2017-07-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does three things: 1.) It simplifies the flag parsing code in `conf.py` to properly display flag definitions created by `.. (ghc|rts)-flag::`. Additionally, all flag references must include the associated arguments. Documentation has been added to `editing-guide.rst` to explain this. 2.) It normalizes all flag definitions to a similar format. Notably, all instances of `<>` have been replaced with `⟨⟩`. All references across the users guide have been updated to match. 3.) It fixes a couple issues with the flag reference table's generation code, which did not handle comma separated flags in the same cell and did not properly reference flags with arguments. Test Plan: `SPHINXOPTS = -n` to activate "nitpicky" mode, which reports all broken references. All remaining errors are references to flags without any documentation. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13980 Differential Revision: https://phabricator.haskell.org/D3778
* Add missing -Wdeprecations flag to the users guideerdeszt2017-06-191-0/+13
|
* user-guide: Add since annotation for -Wcpp-undefErik de Castro Lopo2017-05-271-0/+2
| | | | | | | | | | Reviewers: hvr, bgamari, austin Reviewed By: hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3612
* Don't warn about variable-free strict pattern bindingsSimon Peyton Jones2017-05-091-4/+6
| | | | | See Trac #13646 and the new Note [Pattern bindings that bind no variables]
* users-guide: Fix a variety of warningsBen Gamari2017-05-081-0/+2
| | | | Including #13665.
* Spelling only [ci skip]Gabor Greif2017-02-231-1/+1
|
* Add Wredundant-constraints to list of flags excluded from -WallSiddhanathan Shanmugam2017-02-071-0/+1
| | | | In light of #10635
* Warn on missing home modulesYuras Shumovich2017-01-201-2/+13
| | | | | | | | | | | | | | | | | | | | Introduce a warning, -Wmissing-home-modules, to warn about home modules, not listed in command line. It is usefull for cabal when user fails to list a module in `exposed-modules` and `other-modules`. Test Plan: make TEST=MissingMod Reviewers: mpickering, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2977 GHC Trac Issues: #13129
* Update levity polymorphismRichard Eisenberg2017-01-191-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly.
* Implement fine-grained `-Werror=...` facilityMaciej Bielecki2016-11-211-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | This patch add new options `-Werror=...`, `-Wwarn=...` and `-Wno-error=...` (synonym for `-Wwarn=...`). Semantics: - `-Werror` marks all warnings as fatal, including those that don't have a warning flag, and CPP warnings. - `-Werror=...` enables a warning and marks it as fatal - `-Wwarn=...` marks a warning as non-fatal, but doesn't disable it Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: mpickering, svenpanne, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D2706 GHC Trac Issues: #11219
View Lorry Controller Status