diff options
author | George Karachalias <george.karachalias@gmail.com> | 2016-02-03 19:06:45 +0100 |
---|---|---|
committer | Ben Gamari <ben@smart-cactus.org> | 2016-02-04 10:27:36 +0100 |
commit | 28f951edfe50ea5182065144340061ec326781f5 (patch) | |
tree | 0bb7ecd5b29518b0addca890ededb967f09273ca /docs | |
parent | db121b2ec4596b99fed9781ec2d055f29e0d5b20 (diff) | |
download | haskell-28f951edfe50ea5182065144340061ec326781f5.tar.gz |
Overhaul the Overhauled Pattern Match Checker
Overhaul the Overhauled Pattern Match Checker
* Changed the representation of Value Set Abstractions. Instead of
using a prefix tree, we now use a list of Value Vector Abstractions.
The set of constraints Delta for every Value Vector Abstraction is the
oracle state so that we solve everything only once.
* Instead of doing everything lazily, we prune at once (and in general
everything is much stricter). Hence, an example written with pattern
guards is checked in almost the same time as the equivalent with
pattern matching.
* Do not store the covered and the divergent sets at all. Since what we
only need is a yes/no (does this clause cover anything? Does it force
any thunk?) We just keep a boolean for each.
* Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`.
Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should
the default `n` be.
* When a guard is for sure not going to contribute anything, we treat
it as such: The oracle is not called and cases `CGuard`, `UGuard` and
`DGuard` from the paper are not happening at all (the generation of a
fresh variable, the unfolding of the pattern list etc.). his combined
with the above seems to be enough to drop the memory increase for test
T783 down to 18.7%.
* Do not export function `dsPmWarn` (it is now called directly from
within `checkSingle` and `checkMatches`).
* Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle
does not handle type information so using `Id` was a waste of
time/space.
* Added testcases T11195, T11303b (data families) and T11374
The patch addresses at least the following:
Trac #11195, #11276, #11303, #11374, #11162
Test Plan: validate
Reviewers: goldfire, bgamari, hvr, austin
Subscribers: simonpj, thomie
Differential Revision: https://phabricator.haskell.org/D1795
Diffstat (limited to 'docs')
-rw-r--r-- | docs/users_guide/8.0.1-notes.rst | 9 | ||||
-rw-r--r-- | docs/users_guide/bugs.rst | 10 | ||||
-rw-r--r-- | docs/users_guide/using-warnings.rst | 34 |
3 files changed, 0 insertions, 53 deletions
diff --git a/docs/users_guide/8.0.1-notes.rst b/docs/users_guide/8.0.1-notes.rst index 9159026943..10eab700f8 100644 --- a/docs/users_guide/8.0.1-notes.rst +++ b/docs/users_guide/8.0.1-notes.rst @@ -287,15 +287,6 @@ Compiler warns in the case of unused term-level patterns. Both flags are implied by :ghc-flag:`-W`. -- Added the :ghc-flag:`-Wtoo-many-guards` flag. When enabled, this will issue a - warning if a pattern match contains too many guards (over 20 at the - moment). Makes a difference only if pattern match checking is also enabled. - -- Added the :ghc-flag:`-ffull-guard-reasoning` flag. When enabled, pattern match - checking tries its best to reason about guards. Since the additional - expressivity may come with a high price in terms of compilation time and - memory consumption, it is turned off by default. - - :ghc-flag:`-this-package-key` has been renamed again (hopefully for the last time!) to :ghc-flag:`-this-unit-id`. The renaming was motivated by the fact that the identifier you pass to GHC here doesn't have much to do with packages: diff --git a/docs/users_guide/bugs.rst b/docs/users_guide/bugs.rst index 8304e25e78..f0c522cf75 100644 --- a/docs/users_guide/bugs.rst +++ b/docs/users_guide/bugs.rst @@ -358,16 +358,6 @@ Bugs in GHC This flag ensures that yield points are inserted at every function entrypoint (at the expense of a bit of performance). -- GHC's updated exhaustiveness and coverage checker (see - :ref:`options-sanity`) is quite expressive but with a rather high - performance cost (in terms of both time and memory consumption), mainly - due to guards. Two flags have been introduced to give more control to - the user over guard reasoning: :ghc-flag:`-Wtoo-many-guards` - and :ghc-flag:`-ffull-guard-reasoning` (see :ref:`options-sanity`). - When :ghc-flag:`-ffull-guard-reasoning` is on, pattern match checking for guards - runs in full power, which may run out of memory/substantially increase - compilation time. - - GHC does not allow you to have a data type with a context that mentions type variables that are not data type parameters. For example: diff --git a/docs/users_guide/using-warnings.rst b/docs/users_guide/using-warnings.rst index afcee5b5d7..7fd2019cc6 100644 --- a/docs/users_guide/using-warnings.rst +++ b/docs/users_guide/using-warnings.rst @@ -527,40 +527,6 @@ of ``-W(no-)*``. This option isn't enabled by default because it can be very noisy, and it often doesn't indicate a bug in the program. -.. ghc-flag:: -Wtoo-many-guards - -Wno-too-many-guards - - .. index:: - single: too many guards, warning - - The option :ghc-flag:`-Wtoo-many-guards` warns about places where a - pattern match contains too many guards (over 20 at the moment). - It has an effect only if any form of exhaustivness/overlapping - checking is enabled (one of - :ghc-flag:`-Wincomplete-patterns`, - :ghc-flag:`-Wincomplete-uni-patterns`, - :ghc-flag:`-Wincomplete-record-updates`, - :ghc-flag:`-Woverlapping-patterns`). When enabled, the warning can be - suppressed by enabling either :ghc-flag:`-Wno-too-many-guards`, which just - hides the warning, or :ghc-flag:`-ffull-guard-reasoning` which runs the - full check, independently of the number of guards. - -.. ghc-flag:: -ffull-guard-reasoning - - :implies: :ghc-flag:`-Wno-too-many-guards` - - .. index:: - single: guard reasoning, warning - - The option :ghc-flag:`-ffull-guard-reasoning` forces pattern match checking - to run in full. This gives more precise warnings concerning pattern - guards but in most cases increases memory consumption and - compilation time. Hence, it is off by default. Enabling - :ghc-flag:`-ffull-guard-reasoning` also implies :ghc-flag:`-Wno-too-many-guards`. - Note that (like :ghc-flag:`-Wtoo-many-guards`) :ghc-flag:`-ffull-guard-reasoning` - makes a difference only if pattern match checking is already - enabled. - .. ghc-flag:: -Wmissing-fields .. index:: |