GitLab

An upcoming commit means that the RULES for 'seq' get only
one value arg, not two.  This patch prepares for that by

- reducing the arity of seq's built-in rule, to take one value arg
- making 'seq' not inline on the LHS of RULES
- and removing the horrid un-inlining in DsBinds.decomposeRuleLhs

Summary:
In the following code fragment

    let ls :: Int = undefined

the `::` is attached to the ls function as a whole, rather than to the
pattern on the LHS.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

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

GHC Trac Issues: #10396

Summary:
In the following code, the extra set of parens around the context end up
with detached annotations.

    {-# LANGUAGE PartialTypeSignatures #-}
    module ParensAroundContext where

    f :: ((Eq a, _)) => a -> a -> Bool
    f x y = x == y

Trac ticket #10354

It turns out it was the TupleTy that was the culprit.

This may also solve #10315

Test Plan: ./validate

Reviewers: hvr, austin, goldfire

Reviewed By: austin

Subscribers: goldfire, bgamari, thomie, mpickering

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

GHC Trac Issues: #10354, #10315

Summary:
When parsing

    {-# LANGUAGE ScopedTypeVariables #-}

    extremumNewton :: forall tag. forall tag1.
                       tag -> tag1 -> Int
    extremumNewton = undefined

the parser creates nested HsForAllTy's for the two forall statements.

These get flattened into a single one in `HsTypes.mk_forall_ty`

This patch removes the flattening, so that API Annotations are not lost in the
process.

Test Plan: ./validate

Reviewers: goldfire, austin, simonpj

Reviewed By: simonpj

Subscribers: bgamari, mpickering, thomie, goldfire

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

GHC Trac Issues: #10278, #10315, #10354, #10363

Thanks to Christiaan Baaj for spotting this.

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

Fixes Trac #10430.

Apparently my machine likes this commit, but Harbormaster does not?

This reverts commit b199536b.

As Reid mentioned in a comment on D894, the case fixed by this revision
likely isn't really correct, because old ARM binaries could run on newer
machines, meaning we need to detect at runtime whether we need a proper
barrier.

But in the mean time, this actually stops the build from failing - which
is better off. So we'll just remember this when we fix it in the future.
Signed-off-by: Austin Seipp <austin@well-typed.com>

This reverts commit b0b11ad9.

It apparently made Harbormaster sad.

When using GHCi, we explicitly reject optimization, because the
compilers optimization passes can introduce unboxed tuples, which the
interpreter is not able to handle. But this goes the other way too: using
GHCi on optimized code may cause the optimizer to float out breakpoints
that the interpreter introduces. This manifests itself in weird ways,
particularly if you as an API client use custom DynFlags to introduce
optimization in combination with HscInterpreted.

It turns out we weren't checking for consistent DynFlag settings when
doing `setSessionDynFlags`, as #10052 showed. While the main driver
handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
elsewhere.

This does a little refactoring to split out some of the common code, and
immunizes the various `DynFlags` utilities in the `GHC` module from this
particular bug. We should probably be checking other general invariants
too.

This fixes #10052, and adds some notes about the behavior in `GHC` and
`FloatOut`

As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
didn't exist (somehow).
Signed-off-by: Austin Seipp <austin@well-typed.com>

Reviewed By: edsko

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

GHC Trac Issues: #10052

The OS X dlopen() appears to only resolve undefined symbols in
the direct dependencies of the shared library it is loading.

Reviewed By: trommler, austin

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

GHC Trac Issues: #10322

These behave like the count arguments of the gdb `up` and `down`
commands, allowing the user to quickly jump around in history.

Reviewed By: austin

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

Since GHC requires at least LLVM 3.6, some of the special cases (for,
e.g., LLVM 2.8 or 2.9) in the LLVM CodeGen can be simply removed.

Reviewed By: rwbarton, austin

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

GHC Trac Issues: #10074

This fixes the documentation for -Wall.
As was done previously it leaves out deprecated flags and also
fwarn-safe and fwarn-unsafe. I don't know
if that was intended or not. -fwarn-safe and fwarn-unsafe are
not mentioned on the warnings page at all instead they are
mentioned in the safe haskell section.

Reviewed By: austin

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

GHC Trac Issues: #10386

Module C imports a from Module A and b from module B. B does not
import anything from A. So if ld is configured to drop DT_NEEDED
tags for libraries it does not depend on no DT_NEEDED tag for the
temporary shared object containing module A is recorded in the temp
SO containing module B. This leads to an undefined symbol when
linking the temp SO for module C.

Fixes #10110.

Reviewed By: austin

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

GHC Trac Issues: #10110

Assuming there is no real SMP systems on these CPUs
I've added only compiler barrier (otherwise write_barrier
and friends need to be fixed as well).

Patch also fixes build breakage reported in #10244.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Reviewers: rwbarton, nomeata, austin

Reviewed By: nomeata, austin

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10244

This change makes the matchable-given check apply uniformly to
     - constraint tuples
     - natural numbers
     - Typeable
as well as to vanilla class constraints.

See Note [Instance and Given overlap] in TcInteract

Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
    class (c1, c2) => (c2, c2)

This change was provoked by

  #10359  inability to re-use a given tuple
          constraint as a whole

  #9858   confusion between term tuples
          and constraint tuples

but it's generally a very nice simplification. We get rid of
 -  In Type, the TuplePred constructor of PredTree,
    and all the code that dealt with TuplePreds
 -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

See Note [How tuples work] in TysWiredIn.

Of course, nothing is ever entirely simple. This one
proved quite fiddly.

- I did quite a bit of renaming, which makes this patch
  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

- I made constraint tuples known-key rather than wired-in.
  This is different to boxed/unboxed tuples, but it proved
  awkward to have all the superclass selectors wired-in.
  Easier just to use the standard mechanims.

- While I was fiddling with known-key names, I split the TH Name
  definitions out of DsMeta into a new module THNames.  That meant
  that the known-key names can all be gathered in PrelInfo, without
  causing module loops.

- I found that the parser was parsing an import item like
      T( .. )
  as a *data constructor* T, and then using setRdrNameSpace to
  fix it.  Stupid!  So I changed the parser to parse a *type
  constructor* T, which means less use of setRdrNameSpace.

  I also improved setRdrNameSpace to behave better on Exact Names.
  Largely on priciple; I don't think it matters a lot.

- When compiling a data type declaration for a wired-in thing like
  tuples (,), or lists, we don't really need to look at the
  declaration.  We have the wired-in thing!  And not doing so avoids
  having to line up the uniques for data constructor workers etc.
  See Note [Declarations for wired-in things]

- I found that FunDeps.oclose wasn't taking superclasses into
  account; easily fixed.

- Some error message refactoring for invalid constraints in TcValidity

- Haddock needs to absorb the change too; so there is a submodule update

Previously, the hash function used to cut down the number of block
comparisons did not take local registers into account, causing far too
many similar, but different bocks to be considered candidates for the
(expensive!) comparision.

Adding register to the hash takes CmmCommonBlockElim's share of the
runtime of the example in #10397 from 17% to 2.5%, and eliminates all
unwanted hash collisions.

This patch also replaces the fancy trie by a plain Data.Map. It turned
out to be not performance critical, so this simplifies the code.

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

When working on #10397, I noticed that "reorder" in
nativeCodeGen/seqBlocks took more than 60% of the time. With this
refactoring, it does not even show up in the profile any more. This
fixes #10422.

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

This is an attempt to improve the situation described in #10397, where
the linear scan of possible candidates for commoning up is far too
expensive. There is (ever) more room for improvement, but this is a
start.

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

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

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

Do not check dir perms when .ghci doesn't exist, otherwise GHCi will
print some confusing and useless warnings in some cases (e.g. in travis).
This will fix test T8333 and T10408A in travis.

T10408A will be a test case to cover this. And T8333 is changed to be
not affected by this.

Test Plan:
  chmod o+w ~/.ghc
  make TESTS="T8333 T10408A T10408B"
  chmod o-w ~/.ghc

Reviewers: austin, nomeata

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

This reverts multiple commits from Simon:

  - 04a484ea Test Trac #10359
  - a9ccd37a Test Trac #10403
  - c0aae6f6 Test Trac #10248
  - eb6ca851 Make the "matchable-given" check happen first
  - ca173aa3 Add a case to checkValidTyCon
  - 51cbad15 Update haddock submodule
  - 6e1174da Separate transCloVarSet from fixVarSet
  - a8493e03 Fix imports in HscMain (stage2)
  - a154944b Two wibbles to fix the build
  - 5910a1bc Change in capitalisation of error msg
  - 130e93aa Refactor tuple constraints
  - 8da785d5 Delete commented-out line

These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.

This change makes the matchable-given check apply uniformly to
     - constraint tuples
     - natural numbers
     - Typeable
as well as to vanilla class constraints.

See Note [Instance and Given overlap] in TcInteract

Apparently when Haddock'ing, we check GHC.Prim.
So checkValidTyCon must not crash when dealing with
PrimTyCons; and it was doing so in dataConStupidTheta.

The fix is easy, but I'm puzzled about why Haddock needs to
typecheck GHC.Prim.

The location of setRdrNameSpace has changed in GHC.

(Sadly, the build still fails with a tyConStupidTheta failure in
a haddock invocation; I have no idea why.  But at least Haddock
itself builds.)

I wasn't clear about the distinction before, and that led to a bug
when I refactored FunDeps.oclose to use transCloVarSet; it should
use fixVarSet.