GitLab

There's no obvious reason to derive the definition of `showList`,
manually inlining the default definition. Let's just use
the default definition in the usual manner.

Garbage collect a few unused `RdrNames` from `PrelNames`:
`showList`, `showList__`, and `/=`.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3403

Moritz Angermann reports mysterious rts crash:
  A: link: internal error: schedule: invalid what_next field
  A:     (GHC version 8.3.20170321 for arm_none_linux_android)

This change prints actual prev_what_next value.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Unregisterised GHC can only use C as a target backend
(option used to be called -fvia-C). -fasm option was
ignored with a warhing, but not -fllvm.

jms noticed the failure when tried to use quick-cross
build flavour. quick-cross enables -fllvm in makefile.

  "inplace/bin/ghc-stage1" ... -fllvm
  ghc-stage1: panic! (the 'impossible' happened)
    (GHC version 8.0.2 for powerpc-unknown-linux):
          LlvmCodeGen.Ppr: Cross compiling without valid target info.

This change ignores -fllvm as well.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

It was expensive, as the simplifier runs for many iterations,
and probably not very useful.

Test Plan: harbormaster

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, thomie

Differential Revision: https://phabricator.haskell.org/D3391

When GHCi tries to find a shared lib, it calls "gcc --print-file-name"
to ask gcc where to find it.  But since we're looking for libraries,
we're really using the linker here, not the C compiler, so we should be
respecting the values of -pgml and -optl rather than -pgmc and -optc.

Test Plan: validate

Reviewers: bgamari, niteria, austin, hvr, erikd

Reviewed By: bgamari

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3393

The Join points commit (8d5cf8bf) introduced a space leak
somewhere in the simplifier. The extra strictness added in this commit
fixes the leak. Unfortunately I don't really understand the details.

Unfortunately, the extra strictness appears to result in more overall
allocations in some cases, even while the peak heap size decreases in others.

Test Plan: harbormaster

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D3399

In Core, Constraint should be considered fully equal to
TYPE LiftedRep, in all ways. Accordingly, coreView should
unwrap Constraint to become TYPE LiftedRep. Of course, this
would be a disaster in the type checker.

So, where previously we used coreView in both the type checker
and in Core, we now have coreView and tcView, which differ only
in their treatment of Constraint.

Historical note: once upon a past, we had tcView distinct from
coreView. Back then, it was because newtypes were unwrapped in
Core but not in the type checker. The distinction is back, but
for a different reason than before.

This had a few knock-on effects:

 * The Typeable solver must explicitly handle Constraint to ensure
   that we produce the correct evidence.

 * TypeMap now respects the Constraint/Type distinction

Finished by: bgamari

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3316

This small refactoring, provoked by comment:18 on Trac #13426,
makes it so that simplExprF never gets a (Type ty) expression to
simplify, which in turn means that calls to exprType on its argument
will always succeed.

No change in behaviour.

These checks, introduced in cea71418
hugely inflated build logs, which incapitated perf.haskell.org.

According to Richard, the checks are useless and wrong, and that Ben
plans to investigate.
(https://phabricator.haskell.org/rGHCcea7141851ce653cb20207da3591d09e73fa396d#64647)

Until that happens, I remove them from the code.

Make `Functor`, `Foldable`, and `Traversable` take advantage
of the case where the type parameter is phantom. In this case,

* `fmap _ = coerce`
* `foldMap _ _ = mempty`
* `traverse _ x = pure (coerce x)`

For the sake of consistency and especially simplicity, make other types
with no data constructors behave the same:

* `fmap _ x = case x of`
* `foldMap _ _ = mempty`
* `traverse _ x = pure (case x of)`

Similarly, for `Generic`,

* `to x = case x of`
* `from x = case x of`

Give all derived methods for types without constructors appropriate
arities. For example,

```
    compare _ _ = error ...
```

rather than

```
    compare = error ...
```

Fixes #13117 and #13328

Reviewers: austin, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: ekmett, RyanGlScott, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3374

The #13491 manifests best when we try to crosscompile
from 32-bit (i386-linux) to 64-bit (powerpc64-linux)
system:
    ./configure --target=powerpc64-unknown-linux-gnu

The build fails at assembly time:
  "inplace/bin/ghc-stage1" ...  -c rts/StgStartup.cmm
    /tmp/ghc19687_0/ghc_4.s: Assembler messages:

    /tmp/ghc19687_0/ghc_4.s:11:0: error:
         Error: unknown pseudo-op: `.l'
       |
    11 | .L<\x00>4:
       | ^

That happens because UNIQUE_BITS is defined in terms
of WORD_SIZE_IN_BITS macro:
    #define UNIQUE_BITS (WORD_SIZE_IN_BITS - 8)

WORD_SIZE_IN_BITS is 64 bits (equals to target value)
while ghc-stage1 is still running on i386-linux

The fix is to stop relying on target macros and use
host's 'sizeof (HsInt)' and 'finiteBitSize' way to
determine unique layout.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: build i386-to-powerpc64 crosscompiler

Reviewers: rwbarton, austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, thomie

Differential Revision: https://phabricator.haskell.org/D3397

The idea is to implement a mechanism similar to PureScript, where they
suggest which identifiers in scope would fit the given hole. In
PureScript, they use subsumption (which is what we would like here as
well). For subsumption, we would have to check each type in scope
whether the hole is a subtype of the given type, but that would require
`tcSubType` and constraint satisfiability checking. Currently,
`TcSimplify` uses a lot of functions from `TcErrors`, so that would
require more of a rewrite, I will hold on with that for now, and submit
the more simpler type equality version.

As an example, consider

```
ps :: String -> IO ()
ps = putStrLn

ps2 :: a -> IO ()
ps2 _ = putStrLn "hello, world"

main :: IO ()
main = _ "hello, world"
```

The results would be something like

```
    • Found hole: _ :: [Char] -> IO ()
    • In the expression: _
      In a stmt of a 'do' block: _ "hello, world"
      In the expression:
        do _ "hello, world"
    • Relevant bindings include
        main :: IO () (bound at test.hs:13:1)
        ps :: String -> IO () (bound at test.hs:7:1)
        ps2 :: forall a. a  -> IO () (bound at test.hs:10:1)
      Valid substitutions include
        putStrLn :: String
                    -> IO () (imported from ‘Prelude’ at
test.hs:1:1-14
                              (and originally defined in
‘System.IO’))
        putStr :: String
                  -> IO () (imported from ‘Prelude’ at
test.hs:1:1-14
                            (and originally defined in ‘System.IO’))
```

We'd like here for ps2 to be suggested as well, but for that we require
subsumption.

Reviewers: austin, bgamari, dfeuer, mpickering

Reviewed By: dfeuer, mpickering

Subscribers: mpickering, Wizek, dfeuer, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3361

- Better test for SHT_INIT_ARRAY than openbsd_HOST_OS
  This is actually bens patch:
  https://gist.github.com/bgamari/c846e6a5f2cd988716cd5e36c68d5bef
- linux-android defines.
- No need for -lpthread on OSAndroid
  However, I’m confused why we do not use the AC NEED_PTHREAD_LIB
  value here?
- Use mmap on android
- Support `none` vendor.

Reviewers: austin, hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D3356

Reviewers: austin, hvr, rwbarton, bgamari

Reviewed By: rwbarton, bgamari

Subscribers: rwbarton, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D3348

Fixes #13454

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: RyanGlScott, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3379

It is sometimes hard to find where a rule is defined. Printing the
module where it comes from will make it much easier to find.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3378

Changes in a few different places to catch several different
types of error related to RecursiveDo
Signed-off-by: Rupert Horlick <ruperthorlick@gmail.com>

Test Plan: Three test cases, with further tests in comments

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D3271

This fixes #13489.

This fixes Trac #13494, by improving

   commit e0ad55f8
   Author: Simon Peyton Jones <simonpj@microsoft.com>
   Date:   Mon Mar 27 10:32:08 2017 +0100

   Fix error-message suppress on given equalities

which in turn was a fix to #13446

Just for future (and past) debugging...

Trac #13410 was failing because we had a RULE with a binder
   (c :: t~t)
and the /occurrences/ of c on the LHS were being optimised to Refl,
leaving a binder that would not be filled in by matching the LHS
of the rule.

I flirted with trying to ensure that occurrences (c :: t~t) are
not optimised to Relf, but that turned out to be fragile; it was
being done, for good reasons, in multiple places, including
  - TyCoRep.substCoVarBndr
  - Simplify.simplCast
  - Corecion.mkCoVarCo

So I fixed it in one place by making Rules.matchN deal happily
with an unbound binder (c :: t~t).  Quite easy.  See "Coercion
variables" in Note [Unbound RULE binders] in Rules.

In addition, I needed to make CoreLint be happy with an bound
RULE binder that is a Relf coercion variable

In debugging this, I was perplexed that occurrences of a variable
(c :: t~t) mysteriously turned into Refl.  I found out how it
was happening, and decided to move it:

* In TyCoRep.substCoVarBndr, do not substitute Refl for a
  binder (c :: t~t).

* In mkCoVarCo do not optimise (c :: t~t) to Refl.

Instead, we do this optimisation in optCoercion (specifically
opt_co4) where, surprisingly, the optimisation was /not/
being done.  This has no effect on what programs compile;
it just moves a relatively-expensive optimisation to optCoercion,
where it seems more properly to belong.  It's actually not clear
to me which is really "better", but this way round is less
surprising.

One small simplifying refactoring

* Eliminate TyCoRep.substCoVarBndrCallback, which was only
  called locally.

As #13479 shows, there are corner cases where the simplifier decides to
not eta-expand a function as much as its call arity would suggest, but
instead transforms the code that the call arity annotation becomes a
lie.

As the call arity information is only meant to be used by the
immediatelly following simplifier run, it makes sense to simply zap the
information there.

Differential Revision: https://phabricator.haskell.org/D3390

Test Plan: validate

Reviewers: bgamari, austin, erikd

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3387

Summary: See comments for details.

Test Plan: validate

Reviewers: mpickering, bgamari, austin, erikd

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3386

Do not attempt to typecheck both directions of an
implicitly-bidirectional pattern synonym simultanously,
as we were before.  Instead, the builder is typechecked
when we typecheck the code for the builder, which was
of course happening already, even in both bidirectional
cases.

See Note [Checking against a pattern signature], under
"Existential type variables".

Core Lint shouldn't check representations of types that don't
have representations.

test case: typecheck/should_compile/T13458

The commit 67465497
    Author: Richard Eisenberg <eir@cis.upenn.edu>
    Date:   Fri Dec 11 18:19:53 2015 -0500

    Add kind equalities to GHC.

added this entirely bogus code to Simplify.simplLam:

    env' | Coercion co <- arg
         = extendCvSubst env bndr co
         | otherwise
         = env

It's bogus because 'co' is an 'InCoercion', but a CvSubst should have
only OutCoercions in it.  Moreover, completeBind does the job nicely.

This led to an ASSERT failure in an experimental branch; but I have
not got a repro case that works on HEAD.  But still, the patch deletes
code and fixes a bug, so it must be good.

The only mystery is why Richard added it in the first place :-).
I hope I'm not missing anything.  But it validates fine.

In initTc, if the computation fails with an exception, we
should not complain about unsolved constraints.

Fixes Trac #13466.

I'd got the logic slightly wrong when reporting type errors
for insoluble 'given' equalities.  We suppress insoluble givens
under some circumstances (see Note [Given errors]), but we then
suppressed subsequent 'wanted' errors because the (suppressed)
'given' error "won".  Result: no errors at all :-(.

This patch fixes it and
 - Renames TcType.isTyVarUnderDatatype to the more
   perspicuous TcType.isInsolubleOccursCheck

In doing this I realise that I don't understand why we need
to keep the insolubles partitioned out separately at all...
but that is for another day.

This partly fixes Trac #13441, at least for the explicitly
bidirectional case.

See Note [Checking against a pattern signature], the part about
"Existential type variables".

Alas, the implicitly-bidirectional case is still not quite right, but
at least there is a workaround by making it explicitly bidirectional.