GitLab

It now understand the ghc-stage[123] names we use in-tree, and it won't
go looking for any old ghc-pkg if it can't find the one that matches
ghc.

Broken by "Split part of the Task struct into a separate struct
InCall".

Default currently NO.

Validate passed with GhcDynamic=YES on x86/Linux here.

The compiler is currently slower on x86 when linked -dynamic,
because the GC inner loop has been adversely affected by -fPIC, I'm
looking into how to fix it.

When GHCi is linked dynamically, we still want to be able to load
non-dynamic object files.

We were failing to externalise the wrapper id for a function
that had one.

We really want to know about this!

This patch moves various functions that extract the binders
from a HsTyClDecl, HsForeignDecl etc into HsUtils, and gives
them consistent names.

Warning about useless UNPACK pragmas wasn't as easy as I thought.
I did quite a bit of refactoring, which improved the code by refining
the types somewhat.  In particular notice that in DataCon, we have

    dcStrictMarks   :: [HsBang]
    dcRepStrictness :: [StrictnessMarks]

The former relates to the *source-code* annotation, the latter to
GHC's representation choice.

The tcg_dus field used to contain *uses* of type and class decls,
but not *defs*.  That was inconsistent, and it really went wrong
for Template Haskell bracket.  What happened was that
 foo = [d| data A = A
       	   f :: A -> A
       	   f x = x |]
would find a "use" of A when processing the top level of the module,
which in turn led to a mkUsageInfo panic in MkIface.  The cause was
the fact that the tcg_dus for the nested quote didn't have defs for
A.

The issue here is that 

    g :: A -> A
    f
    data A = A

is treated as if you'd written $(f); that is the call of
f is a top-level Template Haskell splice.  This patch 
makes sure that we *first* check the -XTemplateHaskellFlag
and bleat about a parse error if it's off.  Othewise we
get strange seeing "A is out of scope" errors.

This is in the constraint simplifier which I'm about
to rewrite, so I'm hoping the assert isn't fatal!

It's tricky to set up the context for a Data instance.  I got it wrong
once, and fixed it -- hence the "extra_constraints" in
TcDeriv.inferConstraints.  

But it still wasn't right!  The tricky bit is that dataCast1 is only
generated when T :: *->*, and dataCast2 when T :: *->*->*. (See
the code in TcGenDeriv for dataCastX.

Just a missing case; I've eliminated the catch-all so 
that we get a warning next time we extend HsPat

The renamer wasn't computing the free variables of a type declaration
properly.  This patch refactors a bit, and makes it more robust,
fixing #3955 and several other closely-related bugs.  (We were
omitting some free variables and that could just possibly lead to a
usage-version tracking error.

We now have a DeprecatedFullText constructor, so we can override the
"-#include is deprecated: " part of the warning.

This opportunity was spotted by Roman, and is documented in 
Note [Add demands for strict constructors] in DmdAnal.

See Note [Interaction of exprIsCheap and lone variables] in CoreUnfold

This buglet meant that a nullary definition with an INLINE pragma
counter-intuitively didn't get inlined at all.  Roman identified
the bug.

This patch has zero effect.  It includes comments,
a bit of refactoring, and a tiny bit of commment-out
code go implement the "matching cases" idea below.

In the end I've left it disabled because while I think
it does no harm I don't think it'll do any good either.
But I didn't want to lose the idea totally. There's
a thread called "Storable and constant memory" on
the libraries@haskell.org list (Apr 2010) about it.

Note [Matching cases]
~~~~~~~~~~~~~~~~~~~~~
{- NOTE: This idea is currently disabled.  It really only works if
         the primops involved are OkForSpeculation, and, since
	 they have side effects readIntOfAddr and touch are not.
	 Maybe we'll get back to this later .  -}
  
Consider
   f (case readIntOffAddr# p# i# realWorld# of { (# s#, n# #) ->
      case touch# fp s# of { _ -> 
      I# n# } } )
This happened in a tight loop generated by stream fusion that 
Roman encountered.  We'd like to treat this just like the let 
case, because the primops concerned are ok-for-speculation.
That is, we'd like to behave as if it had been
   case readIntOffAddr# p# i# realWorld# of { (# s#, n# #) ->
   case touch# fp s# of { _ -> 
   f (I# n# } } )