GitLab

This also fixes the internal crash when using pattern synonyms
in GHCi (#8749)

This patch allows turning on ImpredicativeTypes while type-checking
the code generated by GeneralizedNewtypeDeriving. It does this
by adding a field ib_extensions to InstBindings, informing the
type-checker what extensions should be enabled while type-checking
the instance.

the ConTag may be out of range (e.g. if the type constructor is imported
via SOURCE and we don't know any of its data constructors); just return
Nothing without complaining in that case. This fixes #8743.

End of Cmm pipeline used to be split into two alternative flows,
depending on whether we did proc-point splitting or not. There
was a lot of code duplication between these two branches. But it
wasn't really necessary as the differences can be easily enclosed
within an if-then-else. I observed no impact of this change on
compilation performance.

  * CmmRewriteAddignments module was replaced by CmmSink a long
    time ago. That module is now available at
    https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Hoopl/Examples
    wiki page.

  * removeDeadAssignments function was not used and it was also
    moved to the above page.

  * I also nuked some commented out debugging code that was not
    used for 1,5 year.

It turns out that one of the cases in the optimization pass was
a special case of another. I remove that specialization since it
does not have impact on compilation time, and the resulting Cmm
is identical.

Fixes #8585

When emmiting label of a self-recursive tail call (ie. when
performing loopification optimization) we emit the loop header
label after a stack check but before the heap check. The reason is
that tail-recursive functions use constant amount of stack space
so we don't need to repeat the check in every loop. But they can
grow the heap so heap check must be repeated in every call.
See Note [Self-recursive tail calls] and [Self-recursive loop header].

We want it to show up in GHC.Exts, so we need to put the documentation
in GHC.Types, where the datatype Coercible is defined.

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

Fallout from 4ade9627Signed-off-by: Austin Seipp <austin@well-typed.com>

The binutils linker on ARM emits unnecessary R_ARM_COPY relocations
which breaks tables-next-to-code in dynamically linked modules. This
check should be more selective but there is currently no released
version where this bug is fixed.  See
https://sourceware.org/bugzilla/show_bug.cgi?id=16177 and
https://ghc.haskell.org/trac/ghc/ticket/4210#comment:29 for details.
Signed-off-by: Austin Seipp <austin@well-typed.com>

I did some refactoring of the demand analyser, because I was smelling
some minor code smell. Most of my changes I had to undo, though,
adding notes and testcases on why the existing code was correct after
all.

Especially the semantics of the DmdResult is confusing, as it differs in
a DmdType and a StrictSig.

I got to imrpove the readability of the code for lubDmdType, though.

Also, dmdAnalRhs was a bit fishy in how it removed the demand on
further arguments of the body, but used the DmdResult. This would be
wrong if a body would return a demand type of "<L>m" (which currently
does not happen).  This is now treated better in removeDmdTyArgs.

When using TemplateHaskell and -prof, we *do not* want -dynamic-too, because
we're going to *expect* that you compiled the vanilla/dyn way already,
and are compiling profiling the second time (i.e. so GHCi can just load
the normal, non-profiled object files.)
Signed-off-by: Austin Seipp <austin@well-typed.com>

This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
allowing y ou to assign names to a pattern and abstract over it.

The rundown is this:

  * Named patterns are introduced by the new 'pattern' keyword, and can
    be either *unidirectional* or *bidirectional*. A unidirectional
    pattern is, in the simplest sense, simply an 'alias' for a pattern,
    where the LHS may mention variables to occur in the RHS. A
    bidirectional pattern synonym occurs when a pattern may also be used
    in expression context.

  * Unidirectional patterns are declared like thus:

        pattern P x <- x:_

    The synonym 'P' may only occur in a pattern context:

        foo :: [Int] -> Maybe Int
        foo (P x) = Just x
        foo _     = Nothing

  * Bidirectional patterns are declared like thus:

        pattern P x y = [x, y]

    Here, P may not only occur as a pattern, but also as an expression
    when given values for 'x' and 'y', i.e.

        bar :: Int -> [Int]
        bar x = P x 10

  * Patterns can't yet have their own type signatures; signatures are inferred.

  * Pattern synonyms may not be recursive, c.f. type synonyms.

  * Pattern synonyms are also exported/imported using the 'pattern'
    keyword in an import/export decl, i.e.

        module Foo (pattern Bar) where ...

    Note that pattern synonyms share the namespace of constructors, so
    this disambiguation is required as a there may also be a 'Bar'
    type in scope as well as the 'Bar' pattern.

  * The semantics of a pattern synonym differ slightly from a typical
    pattern: when using a synonym, the pattern itself is matched,
    followed by all the arguments. This means that the strictness
    differs slightly:

        pattern P x y <- [x, y]

        f (P True True) = True
        f _             = False

        g [True, True] = True
        g _            = False

    In the example, while `g (False:undefined)` evaluates to False,
    `f (False:undefined)` results in undefined as both `x` and `y`
    arguments are matched to `True`.

For more information, see the wiki:

    https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
    https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/ImplementationReviewed-by: Simon Peyton Jones <simonpj@microsoft.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

by passing the FamInstEnvs all the way down. This closes #7619.

On FreeBSD, /usr/lib has to be added to the library path on linking when
libthr is needed but -nostdlib is used (which is the case when the -prof
and -threaded flags are combined).

See Trac #8672

Fixes Trac #8674

The former adds a newline at the end (restoring the previous behaviour)
while the latter does not (which previously happened by turning the
thuing into a string and only then printing it).

Instead of first checking whether splitting is useful, and then firing
up the worker-wrapper-machinery, which will do the same checks again, we
now simply generate a worker and wrapper, and while doing so keep track
of whether what we did was in any way useful.

So now there is only one place left where we decide whether we want to
do w/w, and that place has access to more information, in particular the
actual types at hand.

these functions were almost equal, and neither validate nor nofib show
any difference replacing one by the other. So lets simplify this.
(This also prepares for a refactoring that will get rid of
worthSplittingArgDmd completely.)

By using the constant-folder to reduce it to an integer.

We occasionally need to reserve some temporary memory in a primop for
passing to a foreign function.  We've been using the stack for this,
but when we moved to high-level Cmm it became quite fragile because
primops are in high-level Cmm and the stack is supposed to be under
the control of the Cmm pipeline.

So this change puts things on a firmer footing by adding a new Cmm
construct 'reserve'.  e.g. in decodeFloat_Int#:

    reserve 2 = tmp {

      mp_tmp1  = tmp + WDS(1);
      mp_tmp_w = tmp;

      /* Perform the operation */
      ccall __decodeFloat_Int(mp_tmp1 "ptr", mp_tmp_w "ptr", arg);

      r1 = W_[mp_tmp1];
      r2 = W_[mp_tmp_w];
    }

reserve is described in CmmParse.y.

Unfortunately the argument to reserve must be a compile-time constant.
We might have to extend the parser to allow expressions with
arithmetic operators if this is too restrictive.

Note also that the return instruction for the procedure must be
outside the scope of the reserved stack area, so we have to extract
the values from the reserved area before we close the scope.  This
means some more local variables (r1, r2 in the example above).  The
generated code is more or less identical to what we had before though.

This fixes a large majority of the testsuite failures on Mavericks with
Clang.
Signed-off-by: Austin Seipp <austin@well-typed.com>