GitLab

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.

I was getting
  docs/users_guide/glasgow_exts.rst:12783:
     WARNING: Title underline too short.

  ``COLUMN`` pragma
  ---------------

So I lengthened the row of hyphens.

In fixing Trac #13337, and introducing solveSomeEqualities,
Richard introduce the higher-order function tc_hs_sig_type_x,
with a solver as its argument.

It turned out that there was a much simpler way to do the
same thing, which this patch implements.  Less code, easier
to grok.  No change in behaviour though.

instead define the structs referred to by
 - SectionFormatInfo
 - ObjectCodeFormatInfo

that were only forward-declared earlier.

This fixes redefinition errors with gcc4.4

Summary:
We were using the unconstrainted `lookupOccRn` function which looked up
any variable in scope. Instead we only want to consider variables brought into
scope by renaming the pattern on the RHS.

A few more changes to make reporting of unbound names suggest the correct
things.

Fixes #13470

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

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

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

This is the final commit that ties them all together. Here we
add the aarch64 linker for macho files.

- In D3238 we started allowing preloading object code with mmap
  in iOS, where we can't have r+w+x.
- In D3239 we introduced a richer extension of the object code
  data type to make working with mach-o files easier.
- In D3240 we set the stage to allow loading archives (.a) on iOS
- In D3251 we added init and deinit functions to populate and
  depopulate the enriched object code data structure for mach-o
  files.
- In D3252 we refactored most of the MachO.c file to use the
  new types and datastructure.

This commit will than finally add the aarch64 (arm64) linker
for mach-o files to ghc, using the improved foundation we
have constructed above.

The dependency structure therefore is as follows

```
  .- D3240
  v
This <- D3252 <- D3251 <- D3239
  ^
  '- D3238
```

Depends: D3252, D3240, D3238

Test Plan:
To test this with iOS, we also need the remote-iserv
diff D3233. With all that in place, proceed as follows:

- Build ghc for the host

```
  ghc $ ./configure --prefix=/test/opt \
    --disable-large-address-space \
    --with-llc=/path/to/llvm-3.9/bin/llc \
    --with-opt=/path/to/llvm-3.9/bin/opt
  # edit mk/build.mk to specify quick
  ghc $ make && make install
```

- Build ghc for ios

```
  ghc $ ./configure --target=aarch64-apple-darwin14 \
    --prefix=/test/opt \
    --disable-large-address-space \
    --with-llc=/path/to/llvm-3.9/bin/llc \
    --with-opt=/path/to/llvm-3.9/bin/opt \
    --with-ghc=/test/bin/ghc \
    --enable-bootstrap-with-devel-snapshot
  # edit mk/build.mk to specify quick-cross
  ghc $ make && make install

```
- Obtain the iOS wrapper scripts from
https://github.com/angerman/ghc-ios-scripts
  and place them in PATH.

- Build iserv-proxy for the host

```
  ghc/iserv $ cabal install -fproxy -flibrary

```
- Build iserv-library for the target

```
  # build cryptonite without integer-gmp
  ghc/iserv $ aarch64-apple-darwin14-cabal install cryptonite
-f-integer-gmp
  ghc/iserv $ aarch64-apple-darwin14-cabal install -flibrary
```

- Create an iOS application with the following `main.m`:
```
  #import <UIKit/UIKit.h>
  #include "HsFFI.h"
  extern void startSlave(bool, int, const char *);

  int main(int argc, char * argv[]) {
    const char * documents_path = [[[NSFileManager defaultManager]
URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask]
firstObject].path.UTF8String;

    hs_init(NULL, NULL);

    startSlave(false, 5000, documents_path);

    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, nil);
    }
  }
```

  and link it with: the iserv archive from
`~/.cabal/lib/aarch64-ios-ghc`
  as well as all dependent archives.

- Build, Install and Launch the iserv-slave application on your iphone

- Compile some Template Haskell code with the
`aarch64-apple-darwin14-ghc`,
  through the `iserv-proxy`

```
  app $ aarch64-apple-darwin14-ghc Module.hs \
   -threaded -staticlib \
   -outputdir build/aarch64 -pgmlibtool libtool-quiet -stubdir . \
   -fexternal-interpreter \
   -pgmi=$HOME/.cabal/bin/iserv-proxy \
   -opti10.0.0.1 \
   -opti5000
```
  where 10.0.0.1 is the ip of your iserv-slave.

  magic.

Reviewers: rwbarton, bgamari, austin, hvr, erikd, simonmar

Subscribers: thomie, erikd, ryantrinkle

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

- Rename existing structs with typedefs from MachOTypes.
- Update the following functions to make use of the
  extended ObjectCode structure:
  - ocAllocateSymbolExtras_MachO
  - resolveImports
  - ocGetNames_MachO
  - ocResolve_MachO
  - ocRunInit_MachO
- repalce int with size_t for fread
- Add aarch64 to the 64bit magic header check.

Depends on D3239, D3251

This is just one of the pieces for the rts linker
support for ios (aarch64-macho)

---

The following diagram and legend tries to explain the dependencies a
bit:
```
  .- D3240
  v
D3255 <- This <- D3251 <- D3239
  ^
  '- D3238
```

- In D3238 we started allowing preloading object code with mmap
  in iOS, where we can't have r+w+x.
- In D3239 we introduced a richer extension of the object code
  data type to make working with mach-o files easier.
- In D3240 we set the stage to allow loading archives (.a) on iOS
- In D3251 we added init and deinit functions to populate and
  depopulate the enriched object code data structure for mach-o
  files.
- In D3252 we refactored most of the MachO.c file to use the
  new types and data structure.
- in D3255 we finally introduce the aarch64-mach-o linker.

Reviewers: austin, rwbarton, erikd, simonmar, bgamari

Subscribers: thomie

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

This adds ocInit_MachO function, used to populate the extended
ObjectCode structure, and the corresponding stgFree.

It also adds defines for iOS, such that MachO.o is also compiled for iOS
targets.

Depends on D3239

---

This is just one of the pieces for the rts linker
support for ios (aarch64-macho)

---

The following diagram and legend tries to explain the dependencies a
bit:
```
  .- D3240
  v
D3255 <- D3252 <- This <- D3239
  ^
  '- D3238
```

- In D3238 we started allowing preloading object code with mmap
  in iOS, where we can't have r+w+x.
- In D3239 we introduced a richer extension of the object code
  data type to make working with mach-o files easier.
- In D3240 we set the stage to allow loading archives (.a) on iOS
- In D3251 we added init and deinit functions to populate and
  depopulate the enriched object code data structure for mach-o
  files.
- In D3252 we refactored most of the MachO.c file to use the
  new types and data structure.
- in D3255 we finally introduce the aarch64-mach-o linker.

Reviewers: rwbarton, bgamari, austin, erikd, simonmar

Subscribers: thomie

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