GitLab

Signed-off-by: Austin Seipp <austin@well-typed.com>

The section of the User Guide in reference is 4.12.4
Signed-off-by: Austin Seipp <austin@well-typed.com>

We creeped back up again past the symbol threshold on my test x86_64
win2k8 test machine. This brings it down to 60600 symbols in split
windows DLL.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Gold apparently doesn't recognize `-z origin`, only `-zorigin` it seems.
Authored-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This was pretty badly broken...
Authored-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

(It improperly used 'show' on the Maybe Int, not the Int.)
Authored-by: Karel Gardas <karel.gardas@centrum.cz>
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

GHCi didn't reset the multiline prompt when an exception (in particular,
the UserInterrupt exception) occured. This commit uses `finally` to
reset the prompt in all cases.

We float equalities out of implications whose 'givens' include equalities.
But it's a bit tricky knowing whether some givens do or do not include
equalities, as #8644 shows.  There the given has type 'c' (which might
have equalities), but we discover that 'c ~ ()', which definitely doesn't.

In short, we must look at the givens *after* normalisation, not before.
Moreover, something similar happens in approximateWC, where we need
to ask whether an implication has given equalities.

This patch does the job:

* Add a Boolean field inert_no_eqs to InertCans, which records
  whether we've added a non-constant equality

* Add a field ic_no_eqs to Implication, which records whether the
  ic_given binders include any equalities

* Get rid of Inst.hasEqualities altogether

On the way I did some un-forced refactoring

* Introduce the auxiliary function TcCanonical.flattenNestedFamApp

* Kill off FamHeadMap and PredMap in favour of
  the new FunEqMap and DictMap respectively

If you say
  ghci> import Foo( T )
  ghci> data T = MkT
  ghci> data T = XXX
then the second 'data T' should shadow the first.  But the qualified
Foo.T should still be available.  We really weren't handling this
correctly at all, resulting in Trac #8639 and #8628 among others

This patch:

* Add RdrName.extendGlobalRdrEnv, which does shadowing properly

* Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv)
  to use the new function

* Change RnNames.extendGobalRdrEnvRn to use the new function

* Move gresFrom Avails into RdrName
* Better pprGlobalRdrEnv function in RdrName

When you say
  ghci> :i Foo.x
GHCi tries to find module Foo and get 'x' from it.  But
if Foo doesn't exist we don't want to say:
  Attempting to use module ‛Foo’ which is not loaded

This is a bit confusing. Rather we just want to say that
Foo.x is not in scope.

I'm not sure why were were using bindLocalNames before, but it triggers
an assert failure that checks that local names are Internal.  This
change makes things more uniform and straightforward.

Fixes Trac #8640

This fixes Trac #8625

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is a substantial refactoring of the canonicaliser. The proximate
cause was that we were sometimes failing to correctly orient a
tyvar/tyvar equality (x ~ y), because the kind of x or y was not fully
zonked at the moment we compared them.  That in turn led me to look
closely at the way that canEvNC (which decomposes equalities) worked.

* The big change is that the 'reOrient' and 'classify' functions are gone,
  along with classify's 'TypeClassifier' return type.  Instead the
  re-orientation is built into canEqNC.  When we find a type variable
  we divert into canEqTyVar, and so on, very much as in TcUnify.

* TcCanonical.canEqTyVar, canEqLeafFun, etc now carry a SwapFlag (to
  reduce duplication), just as in TcUnify; now SwapFlag itself is
  defined in BasicTypes

* I renamed TcSMonad.rewriteCtFlavor to rewriteEvidence,

* I added a new specialised version of rewriteEvidence, called
  TcSMonad.rewriteEqEvidence.  It is easier to use, and removes
  the crafty but brain-mangling higher order casts that we were
  using before.

The result is not exactly simpler, but it's pretty clear and, I think,
significantly more efficient.  And it fixes Trac #8603!

This patch doesn't include the changes to TcCanonical and TcSMonad,
which are a bigger follow-up patch, so it is tightly coupled to the
follow-up.

With the recent modifications to the TH infrastructure, many splices are now
expanded in the renamer rather than the typechecker. This means that tools
which inspect the renamed tree don't get to see the original splices. Added a
new hook which gets called before such a splice gets expanded, analogous to the
runQuasiQuoteHook.

The solution (after many false starts) is to change the behavior of
hsLTyClDeclBinders. The idea is that the locations of the names that
the parser generates should really be the names' locations, unlike
what was done in 17457791... But, when the renamer is creating Names
from the RdrNames, the locations stored in the Names should be the
declarations' locations. This is now achieved in hsLTyClDeclBinders,
which returns [Located name], but the location is that of the
*declaration*, not the name itself.

This reverts commit 17457791.

This is part of the fix for #8607. Only reverting RdrHsSyn.lhs.

Conflicts:

	compiler/parser/RdrHsSyn.lhs
	compiler/typecheck/TcTyClsDecls.lhs

(Closes: #8617)

by only passing the demand on the free variables, and whether the
argument (resp. scrunitee) may or will diverge.

Make different postProcess code paths for function arguments (which are
post-processed just to be both'ed) and unsaturated functions (which are
post-processed for other reasons.)

its first argument is just used for its length (the arity of the call).
So changing the type to Int to reflect that.

Also add a note [Demands from unsaturated function calls] that hopefully
comprehensively and comprehensibly explains what is going on here.

this is a small-step-refactoring patch and not very interesting on its
own.

by adding Notes and using easier to understand combinators.

Joachim and I are committing this onto a branch so that we can share it,
but we expect to do a bit more work before merging it onto head.

Nofib staus:
  - Most programs, no change
  - A few improve
  - A couple get worse (cacheprof, tak, rfib)
Investigating the "get worse" set is what's holding up putting this
on head.

The major issue is this.  Consider

    map (f g) ys

where f's demand signature looks like

   f :: <L,C1(C1(U))> -> <L,U> -> .

So 'f' is not saturated.  What demand do we place on g?
Answer
        C(C1(U))
That is, the inner C1 should stay, even though f is not saturated.

I found that this made a significant difference in the demand signatures
inferred in GHC.IO, which uses lots of higher-order exception handlers.

I also had to add used-once demand signatures for some of the
'catch' primops, so that we know their handlers are only called once.