GitLab

When doing strictness analysis, we need to look inside products.
To avoid unpacking infinitely, we must be careful about
infinite types.  That in turn is controlled by TyCon.checkRecTc.

For data families like
   data instance T (a,b) = MkT a (T b)
we want to unpack the thing recursively for types like
  T (Int, (Int, (Int, Int)))

This patch elaborates the checkRecTc mechanism in TyCon, to
maintain a *count* of how many times a TyCon has shown up,
rather than just a boolean.

A simple change, and a useful one.  Fixes Trac #10482.

When we have
  data instance T (a,b) = MkT a b
we make a represntation type
  data TPair a b = MkT a b
plus an axiom to connect the two
  ax a b :: T (a,b)  ~R  TPair a b

Previously this was a Nominal equality, and that worked ok
but seems illogical since Nominal equalities are between
types that the programmer thinks of as being equal.  But
TPair is not visible to the programmer; indeed we call it
the "representation TyCon".  So a Representational equality
seems more suitable here.

Summary:
On x86_64, commit e2f6bbd3 assigned
the STG registers F1 and D1 the same hardware register (xmm1), and
the same for the registers F2 and D2, etc. When mixing calls to
functions involving Float#s and Double#s, this can cause wrong Cmm
optimizations that assume the F1 and D1 registers are independent.

Reviewers: simonpj, austin

Reviewed By: austin

Subscribers: simonpj, thomie, bgamari

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

GHC Trac Issues: #10521

The main payload is in 'mk_functor_like_constraints' in
TcDeriv.inferConstraints.

This is moving towards a fix for Trac #10561

Reported by mitchty:

  When porting ghc to alpine linux (rumors say they build
  all binaries as Position Independent Executables
  to leverage global ASLR) linker issued obscure errors:

Tiny example:
    $ echo 'main = print "hello"' > a.hs
    $ ghc -fforce-recomp a.hs -fPIC -dynamic -optl-pie -o a
        ld: /tmp/ghc2142_0/ghc2142_5.o: relocation R_X86_64_32 against `ZCMain_main_closure'
            can not be used when making a shared object; recompile with -fPIC
        /tmp/ghc2142_0/ghc2142_5.o: error adding symbols: Bad value
        collect2: error: ld returned 1 exit status

There is two entry points in CC driver:
    'runPhase' (CC) and 'mkExtraObj'

'mkExtraObj' does not handle most of 'runPhase's complexity.
Ideally it should.

This patch only adds -fPIC propagation to 'mkExtraObj'.

Please merge to stable branch.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Summary:
Contains Cabal submodule update, as Cabal is responsible
generating package keys.  We also have to update some output.

Also comes with a documentation update for ghc-pkg in the
user manual for --package-key.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10550

GhcStage1DefaultNewCodegen, GhcStage2DefaultNewCodegen,
GhcStage3DefaultNewCodegen and GhcCompilerWays are not used anywhere.

Summary:
Previously, we used $1_$2_PACKAGE_KEY to parametrize $1.  But the
documentation says that $1 should be the directory...  and we're now
putting the libraries in $1_$2_LIB_NAME.  So use /that/.  This is just
alpha-renaming, so as long as we're consistent, there's no material
difference.)

I also fixed a bug of a package ID calculation which I missed first
time around, which was tickled by this change.

BTW, this means DEP_KEYS and TRANSITIVE_DEP_KEYS are unused, so
remove them from ghc-cabal.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: thomie, bgamari

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

Commit a93ab43a
enabled support for proper PIC relocations from
assembler.

Commit adds support for relocations of type:
    R_PPC_REL16_HI
    R_PPC_REL16_HA
    R_PPC_REL16_LO
    R_PPC_PLTREL24

They are used only when GHC is built in
    DYNAMIC_GHC_PROGRAMS = NO
mode.

Verified by running the following test:

    // cat a.c
    #include <stdio.h>

    void ffi_a_hello (int i) {
        fprintf (stderr, "WEEEEEEEE: i=%d\n", i);
    }

    -- cat A.hs
    {-# LANGUAGE ForeignFunctionInterface #-}
    module A where

    import Foreign.C

    foreign import ccall "ffi_a_hello" a :: CInt -> IO ()

    # ghc -fPIC -c a.c -fforce-recomp
    # ghc -fPIC -c A.hs -fforce-recomp
    # ghc --interactive ./a.o A
    ...
    *A> a 42
    WEEEEEEEE: i=42
See gory details in Trac #10402.
Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Reviewed By: bgamari, austin

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

GHC Trac Issues: #10402

Adding app1, app2, as requested in the ticket

Summary:
When we introduced user-friendly library names
(e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of
unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
be written out by ghc-cabal, $1_$2_LIB_NAME.

What I didn't realize at the time was that this conflicts
with an existing variable in the build system, $1_$2_$3_LIB_NAME,
which (confusingly) refers to something like
'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'.  This is pretty
confusing (despite never conflicting), so I renamed this variable
to LIB_FILE for enhanced greppability.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: thomie, bgamari

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

Summary:
(NB: this code is dead at the moment since Windows is not built
dynamically.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: none

Reviewers: austin

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10551

Summary:
There's not really any good reason to use -package-key over
-package-id, so use the latter as standard practice.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: thomie, bgamari

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

verifying fix for #10348

Reviewers: austin, thomie, alanz

Reviewed By: thomie, alanz

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10556

This should fix T10348

This prevents the following test errors on Windows:

   perf/haddock haddock.Cabal [[Errno 2] No such file or directory: ...
   perf/haddock haddock.base [[Errno 2] No such file or directory: ...
   perf/haddock haddock.compiler [[Errno 2] No such file or directory: ...

The tests will now be reported as having missing libraries.

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

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

Summary:
If we have an orphan rule in our database, don't apply it
unless the defining module is transitively imported by the
module we are processing.  We do this by defining a new RuleEnv
data type which includes both the RuleBase as well as the set
of visible orphan modules, and threading this through the
relevant environments (CoreReader, RuleCheckEnv and ScEnv).

This is analogous to the instances fix we applied in #2182
4c834fdd, but done for RULES.
An important knock-on effect is that we can remove some buggy
code in LoadInterface which tried to avoid loading interfaces
that were loaded by plugins (which sometimes caused instances
and rules to NEVER become visible).

One note about tests: I renamed the old plugins07 test to T10420
and replaced plugins07 with a test to ensure that a plugin
import did not cause new rules to be loaded in.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, goldfire

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10420

Summary:
Previously, we'd install them to something like
xhtml_0ACfOp3hebWD9jGWE4v4G which was fairly ugly; this
commit changes the default install path to contain the full
package name and version, as well as the package key.

Needs a Cabal submodule update for the commit for install paths support
"Add libname install-dirs variable, use it by default. Fixes #2437".
It also contains some miscellaneous fixes for Cabal HEAD.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: bgamari, thomie

Trac Issues: #10479

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

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Observed on a tuple armv7a-hardfloat-linux-gnueabi:
> Unknown vendor hardfloat

Reported-by: Sergey Alirzaev
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Tests use unboxed types (or optimizer gets to them),
those can't be handled by ghci. Fixed by using -fobject-code.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Test sets allocation limit for a current main thread,
ghci already loaded a bunch of stuff in it.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

dblatex can only translate the Unicode glyphs introduced in #10509 for LaTeX
if the `latex.unicode.use=1` flag is set, otherwise it will just fail.
However, note that adding this flag is not going to fully solve the problem as
those symbols are not known by LaTeX, so the corresponding character codes
will be added instead to the resulting PS/PDF files.  Hence it is considered
an interim solution only, not a true fix, until a better one is found.

This was working, and then it started failing again; it's a pretty
fragile test anyway because it 'grep's the output of the compiler.

In the mean time, make the CI system quiet down by marking it
appropriately.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
Parsing

    {-# LANGUAGE TupleSections #-}

    baz = (1, "hello", 6.5,,) 'a' (Just ())

Results in the following AST fragment

    (L tests/examples/Tuple.hs:3:7-25
       (ExplicitTuple
          [ L tests/examples/Tuple.hs:3:8
              (Present
                 (L tests/examples/Tuple.hs:3:8
                    (HsOverLit
                       (OverLit
                          (HsIntegral [ '1' ] 1)
                          PlaceHolder
                          (HsLit
                             (HsString
                                []
                                {abstract:FastString}))
                          PlaceHolder))))
          , L tests/examples/Tuple.hs:3:11-17
              (Present
                 (L tests/examples/Tuple.hs:3:11-17
                    (HsLit
                       (HsString
                          [ '"'
                          , 'h'
                          , 'e'
                          , 'l'
                          , 'l'
                          , 'o'
                          , '"'
                          ]
                          {abstract:FastString}))))
          , L tests/examples/Tuple.hs:3:20-22
              (Present
                 (L tests/examples/Tuple.hs:3:20-22
                    (HsOverLit
                       (OverLit
                          (HsFractional
                             (FL
                                [ '6' , '.' , '5' ]
                                (:% 13 2)))
                          PlaceHolder
                          (HsLit
                             (HsString
                                []
                                {abstract:FastString}))
                          PlaceHolder))))
          , L tests/examples/Tuple.hs:3:24
              (Missing PlaceHolder)
          , L tests/examples/Tuple.hs:3:24
              (Missing PlaceHolder)
          ]

The final `Missing PlaceHolder` has a duplicated `SrcSpan`

Test Plan: ./validate

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, bgamari, mpickering

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

GHC Trac Issues: #10537

This test greps in the ouput of -ddump-simpl, so it's fragile.
It stopped working for a while, but now works again. I don't know
why, but I don't have time to investigate, so I'll just mark it
as ok.