| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
The update of the Outputable instance resulted in a slew of
documentation changes within Notes that used the old syntax.
The most important doc changes are to `Note [Demand notation]`
and the user's guide.
Fixes #19016.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As outlined in #18903, interleaving usage and strictness demands not
only means a more compact demand representation, but also allows us to
express demands that we weren't easily able to express before.
Call demands are *relative* in the sense that a call demand `Cn(cd)`
on `g` says "`g` is called `n` times. *Whenever `g` is called*, the
result is used according to `cd`". Example from #18903:
```hs
h :: Int -> Int
h m =
let g :: Int -> (Int,Int)
g 1 = (m, 0)
g n = (2 * n, 2 `div` n)
{-# NOINLINE g #-}
in case m of
1 -> 0
2 -> snd (g m)
_ -> uncurry (+) (g m)
```
Without the interleaved representation, we would just get `L` for the
strictness demand on `g`. Now we are able to express that whenever
`g` is called, its second component is used strictly in denoting `g`
by `1C1(P(1P(U),SP(U)))`. This would allow Nested CPR to unbox the
division, for example.
Fixes #18903.
While fixing regressions, I also discovered and fixed #18957.
Metric Decrease:
T13253-spj
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
makeTrivial is responsible for concocting names during simplification.
Previously, however, it would make no attempt to generate a name that
might be useful to later readers of the resulting Core. Here we add a
bit of state to SimplEnv: a finite depth stack of binders within which
we are currently simplifying. We then derive generated binders from this
context.
See #11676.
Open questions:
* Is there a better way to accomplish this?
* Is `maxContextDepth` too large/small?
Test Plan: Validate, look at Core.
Reviewers: austin, simonpj
Reviewed By: simonpj
Subscribers: thomie, simonpj
Differential Revision: https://phabricator.haskell.org/D1970
GHC Trac Issues: #11676
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces "freezing," an operation which prevents further
locations from being appended to a CallStack. Library authors may want
to prevent CallStacks from exposing implementation details, as a matter
of hygiene. For example, in
```
head [] = error "head: empty list"
ghci> head []
*** Exception: head: empty list
CallStack (from implicit params):
error, called at ...
```
including the call-site of `error` in `head` is not strictly necessary
as the error message already specifies clearly where the error came
from.
So we add a function `freezeCallStack` that wraps an existing CallStack,
preventing further call-sites from being pushed onto it. In other words,
```
pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack
```
Now we can define `head` to not produce a CallStack at all
```
head [] =
let ?callStack = freezeCallStack emptyCallStack
in error "head: empty list"
ghci> head []
*** Exception: head: empty list
CallStack (from implicit params):
error, called at ...
```
---
1. We add the `freezeCallStack` and `emptyCallStack` and update the
definition of `CallStack` to support this functionality.
2. We add `errorWithoutStackTrace`, a variant of `error` that does not
produce a stack trace, using this feature. I think this is a sensible
wrapper function to provide in case users want it.
3. We replace uses of `error` in base with `errorWithoutStackTrace`. The
rationale is that base does not export any functions that use CallStacks
(except for `error` and `undefined`) so there's no way for the stack
traces (from Implicit CallStacks) to include user-defined functions.
They'll only contain the call to `error` itself. As base already has a
good habit of providing useful error messages that name the triggering
function, the stack trace really just adds noise to the error. (I don't
have a strong opinion on whether we should include this third commit,
but the change was very mechanical so I thought I'd include it anyway in
case there's interest)
4. Updates tests in `array` and `stm` submodules
Test Plan: ./validate, new test is T11049
Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari
Reviewed By: simonpj
Subscribers: thomie
Projects: #ghc
Differential Revision: https://phabricator.haskell.org/D1628
GHC Trac Issues: #11049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch modifies `error`, `undefined`, and `assertError` to use
implicit call-stacks to provide better error messages to users.
There are a few knock-on effects:
- `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
types for `error` and `undefined`.
- `TysPrim.tyVarList` has been replaced with a new function
`TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
subtle bugs when you need tyvars of different kinds. The naive
```
tv1 = head $ tyVarList kind1
tv2 = head $ tyVarList kind2
```
would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
would be applied incorrectly, treating `tv1` and `tv2` as the same
tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
and producing a single tyvar of each kind.
- The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in
ghc-prim.
- The type `GHC.Exception.ErrorCall` has a new constructor
`ErrorCallWithLocation` that takes two `String`s instead of one, the
2nd one being arbitrary metadata about the error (but usually the
call-stack). A bi-directional pattern synonym `ErrorCall` continues to
provide the old API.
Updates Cabal, array, and haddock submodules.
Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari
Reviewed By: simonpj
Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
liyang, bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D861
GHC Trac Issues: #5273
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
