[Git][ghc/ghc][wip/pmcheck-ncon] 6 commits: Add PlainPanic for throwing exceptions without depending on pprint

Sebastian Graf gitlab at gitlab.haskell.org
Mon May 27 11:06:16 UTC 2019



Sebastian Graf pushed to branch wip/pmcheck-ncon at Glasgow Haskell Compiler / GHC


Commits:
d9dfbde3 by Michael Sloan at 2019-05-24T15:55:07Z
Add PlainPanic for throwing exceptions without depending on pprint

This commit splits out a subset of GhcException which do not depend on
pretty printing (SDoc), as a new datatype called
PlainGhcException. These exceptions can be caught as GhcException,
because 'fromException' will convert them.

The motivation for this change is that that the Panic module
transitively depends on many modules, primarily due to pretty printing
code.  It's on the order of about 130 modules.  This large set of
dependencies has a few implications:

1. To avoid cycles / use of boot files, these dependencies cannot
throw GhcException.

2. There are some utility modules that use UnboxedTuples and also use
`panic`. This means that when loading GHC into GHCi, about 130
additional modules would need to be compiled instead of
interpreted. Splitting the non-pprint exception throwing into a new
module resolves this issue. See #13101

- - - - -
70c24471 by Moritz Angermann at 2019-05-25T21:51:30Z
Add `keepCAFs` to RtsSymbols

- - - - -
9be1749d by David Eichmann at 2019-05-25T21:55:05Z
Hadrian: Add Mising Libffi Dependencies #16653

Libffi is ultimately built from a single archive file (e.g.
libffi-tarballs/libffi-3.99999+git20171002+77e130c.tar.gz).
The file can be seen as the shallow dependency for the whole
libffi build. Hence, in all libffi rules, the archive is
`need`ed and the build directory is `trackAllow`ed.

- - - - -
2d0cf625 by Sandy Maguire at 2019-05-26T12:57:20Z
Let the specialiser work on dicts under lambdas

Following the discussion under #16473, this change allows the
specializer to work on any dicts in a lambda, not just those that occur
at the beginning.

For example, if you use data types which contain dictionaries and
higher-rank functions then once these are erased by the optimiser you
end up with functions such as:

```
  go_s4K9
  Int#
  -> forall (m :: * -> *).
     Monad m =>
     (forall x. Union '[State (Sum Int)] x -> m x) -> m ()
```

The dictionary argument is after the Int# value argument, this patch
allows `go` to be specialised.

- - - - -
226e3c0e by Sebastian Graf at 2019-05-27T11:06:15Z
TmOracle: Replace negative term equalities by refutable PmAltCons

The `PmExprEq` business was a huge hack and was at the same time vastly
too powerful and not powerful enough to encode negative term equalities,
i.e. facts of the form "forall y. x ≁ Just y".

This patch introduces the concept of 'refutable shapes': What matters
for the pattern match checker is being able to encode knowledge of the
kind "x can no longer be the literal 5" or "x can no longer be Just y,
for any y". We encode this knowledge in a `PmRefutEnv`, mapping a set of
newly introduced `PmAltCon`s (literals and `ConLike`s) to eac variable
denoting above inequalities.

So, say we have `x ≁ Just ∈ refuts` in the term oracle context and
try to solve an equality like `x ~ Just 5`. The entry in the refutable
environment will immediately lead to a contradiction.

This machinery renders the whole `PmExprEq` business unnecessary,
getting rid of a lot of (mostly dead) code.

Note that the `PmAltConLike` case is currently unnecessary: The `ConVar`
case will just split the value set abstraction for each possible
constructor instead of encoding negative equalites. This is bound to
change in a follow-up patch. If we began to use `PmAltConLike`, we'd
even profit from nicer error messages as is currently the case for
negative literal equalities.

See the Note [Refutable shapes] in TmOracle for a place to start.

- - - - -
2fadc36b by Sebastian Graf at 2019-05-27T11:06:15Z
Add `PmNCons` to `Check` for correct warnings in the presence of `COMPLETE` groups

Previously, we had an elaborate mechanism for selecting the warnings to
generate in the presence of different `COMPLETE` matching groups that,
albeit finely-tuned, produced wrong results from an end user's
perspective in some cases (#13363).

The underlying issue is that at the point where the `ConVar` case has to
commit to a particular `COMPLETE` group, there's not enough information
to do so and the status quo was to just enumerate all possible complete
sets nondeterministically.
The `getResult` function would then pick the outcome according to
metrics defined in accordance to the user's guide. But crucially, it
lacked knowledge about the order in which affected clauses appear,
leading to the surprising behavior in #13363.

The introduction of an `PmNCons` variant in `PmPat` fixes this: Instead
of committing to a particular `COMPLETE` group in the `ConVar` case,
we now split off the matching constructor incrementally and record the
newly covered case in `PmNCons`.
After all clauses have been processed this way, we filter out any value
vector abstractions from the uncovered set involving `PmNCons` whose set
of covered constructors completely overlap a `COMPLETE` set.

- - - - -


30 changed files:

- compiler/basicTypes/NameEnv.hs
- compiler/basicTypes/UniqSupply.hs
- compiler/deSugar/Check.hs
- compiler/deSugar/PmExpr.hs
- + compiler/deSugar/PmPpr.hs
- compiler/deSugar/TmOracle.hs
- compiler/ghc.cabal.in
- compiler/iface/BinFingerprint.hs
- compiler/specialise/Specialise.hs
- compiler/utils/Binary.hs
- compiler/utils/FastString.hs
- compiler/utils/ListSetOps.hs
- compiler/utils/Outputable.hs
- compiler/utils/Panic.hs
- + compiler/utils/PlainPanic.hs
- compiler/utils/Pretty.hs
- compiler/utils/StringBuffer.hs
- compiler/utils/Util.hs
- hadrian/src/Rules/Libffi.hs
- includes/CodeGen.Platform.hs
- rts/RtsSymbols.c
- testsuite/tests/perf/compiler/Makefile
- + testsuite/tests/perf/compiler/T16473.hs
- + testsuite/tests/perf/compiler/T16473.stdout
- testsuite/tests/perf/compiler/all.T
- + testsuite/tests/pmcheck/complete_sigs/T13363a.hs
- + testsuite/tests/pmcheck/complete_sigs/T13363a.stderr
- + testsuite/tests/pmcheck/complete_sigs/T13363b.hs
- + testsuite/tests/pmcheck/complete_sigs/T13363b.stderr
- testsuite/tests/pmcheck/complete_sigs/all.T


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/da159f9becb6f05afc0c8ab1fed1d97b82a43cc2...2fadc36bebf74aa83a165750f04cb02d7d1a2fc8

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/da159f9becb6f05afc0c8ab1fed1d97b82a43cc2...2fadc36bebf74aa83a165750f04cb02d7d1a2fc8
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20190527/858a5452/attachment.html>


More information about the ghc-commits mailing list