Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

Summary:
ld.gold is buggy when using -r and a linker script.  See upstream bug
https://sourceware.org/bugzilla/show_bug.cgi?id=22266

This has been causing various brokenness for the GHC runtime linker,
where we load these broken object files.

Test Plan: Test program from #14675

Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd

Subscribers: rwbarton, thomie, erikd, carter

GHC Trac Issues: #14328, #14675, #14291

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

(cherry picked from commit 0a3629af)

* Clarify the representation of sums without fields.
* Try to improve language, clarity, and examples.

Fixes #14752

Reviewers: osa1, bgamari

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14752

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

(cherry picked from commit d987f71a)

Michal Terepeta authored 7 years ago and Ben Gamari committed 7 years ago

During some recent work on CBE we discovered that `zipWith` is used to
check for equality, but that doesn't quite work if lists are of
different lengths! This was fixed by bgamari, but unfortunately the fix
had to be rolled back due to other changes in CBE in
50adbd7c. Since I wanted to have another
look at CBE anyway, we agreed that the first thing to do would be to
re-introduce the fix.

Sadly I don't have any actual test case that would exercise this.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14226

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

(cherry picked from commit 4e513bf7)

It turns out that one can produce ill-formed Core by
combining `GeneralizedNewtypeDeriving`, `TypeInType`, and
`TypeFamilies`, as demonstrated in #14728. The root of the problem
is allowing the last parameter of a class to appear in a //kind// of
an associated type family, as our current approach to deriving
associated type family instances simply doesn't work well for that
situation.

Although it might be possible to properly implement this feature
today (see https://ghc.haskell.org/trac/ghc/ticket/14728#comment:3
for a sketch of how this might work), there does not currently exist
a performant implementation of the algorithm needed to accomplish
this. Until such an implementation surfaces, we will make this corner
case of `GeneralizedNewtypeDeriving` an error.

Test Plan: make test TEST="T14728a T14728b"

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14728

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

(cherry picked from commit 1ede46d4)

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

By request of @alexbiehl.
CCing @snowleopard and @alpmestan as the same should be done in Hadrian.

Bumps haddock submodule.

Reviewers: alexbiehl

Reviewed By: alexbiehl

Subscribers: rwbarton, thomie, carter, snowleopard, alpmestan, alexbiehl

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

(cherry picked from commit 9ff4cce3)

(cherry picked from commit da468130)

This patch includes two changes:

1. Move cost centre collection from `SCCfinal` to `CorePrep`, to be able
   to collect cost centres in unfoldings. `CorePrep` drops unfoldings, so
   that's the latest stage in the compilation pipeline for this.

   After this change `SCCfinal` no longer collects all cost centres, but
   it still generates & collects CAF cost centres + updates cost centre
   stacks of `StgRhsClosure` and `StgRhsCon`s.

   This fixes #5889.

2. Initialize cost centre stack fields of `StgRhs` in `coreToStg`. With
   this we no longer need to update cost centre stack fields in
   `SCCfinal`, so that module is removed.

   Cost centre initialization explained in Note [Cost-centre
   initialization plan].

   Because with -fcaf-all we need to attach a new cost-centre to each
   CAF, `coreTopBindToStg` now returns `CollectedCCs`.

Test Plan: validate

Reviewers: simonpj, bgamari, simonmar

Reviewed By: simonpj, bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #5889

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

(cherry picked from commit 59574058)

Reviewers: bgamari, simonmar

Reviewed By: simonmar

Subscribers: alexbiehl, rwbarton, thomie, carter

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

(cherry picked from commit 2a78cf77)

Previously, we were skipping over `$tcUnit#` entirely when
wiring in `Typeable` tycons, resulting in #14811. Easily fixed.

Test Plan: make test TEST=T14811

Reviewers: bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, rwbarton, thomie, carter

GHC Trac Issues: #14811

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

(cherry picked from commit d5ac5820)

This change is present in 4.11.0.0.

(cherry picked from commit abecb2619acea5cf6ebaa7412401d9e660daf82c)

When finishing up an implication constraint, it's a bit tricky to
decide which Derived constraints to retain (for error reporting) and
which to discard.  I got this wrong in commit
   f20cf982
   (Remove wc_insol from WantedConstraints)

The particular problem in Trac #14763 was that we were reporting as an
error a fundep-generated constraint
  (ex ~ T)
where 'ex' is an existentially-bound variable in a pattern match.
But this isn't really an error at all.

This patch fixes the problem. Indeed, since I had to understand
this rather tricky code, I took the opportunity to clean it up
and document better.  See
  isDroppableCt :: Ct -> Bool
and Note [Dropping derived constraints]

I also removed wl_deriv altogether from the WorkList data type.  It
was there in the hope of gaining efficiency by not even processing
lots of derived constraints, but it has turned out that most derived
constraints (notably equalities) must be processed anyway; see
Note [Prioritise equalities] in TcSMonad.

The two are coupled because to decide which constraints to put in
wl_deriv I was using another variant of isDroppableCt.  Now it's much
simpler -- and perhaps even more efficient too.

(cherry picked from commit 6edafe3b)

In prelRules we had:

  tx_con_tte :: DynFlags -> AltCon -> AltCon
  tx_con_tte _      DEFAULT      = DEFAULT
  tx_con_tte dflags (DataAlt dc)
    | tag == 0  = DEFAULT   -- See Note [caseRules for tagToEnum]
    | otherwise = LitAlt (mkMachInt dflags (toInteger tag))

The tag==0 case is totally wrong, and led directly to Trac #14768.

See "Beware" in Note [caseRules for tagToEnum] (in the patch).

Easily fixed, though!

(cherry picked from commit 4aa98f4a)

Herbert Valerio Riedel authored 7 years ago and Ben Gamari committed 7 years ago

This was an oversight from 2671cccd
as it wasn't obvious to assume one would go the trouble to manually
construct the pkg-db entries... :-)

(cherry picked from commit be53d19e)

(cherry picked from commit 24e56ebd)

(cherry picked from commit 606edbfb)

Trac #14226 noted that the C-- CBE pass frequently fails to
common up semantically identical blocks due to the differences in local
register naming. These patches fixed this by making the pass consider
equality up to alpha-renaming.

However, the new logic failed to consider the possibility that local
register naming *may* matter across multiple blocks. This lead to the
regression #14754. I'll need to do a bit of thinking on a proper
solution to this but in the meantime I'm reverting all four patches.

This reverts commit a27056f9.
This reverts commit 6f990c54.
This reverts commit 9aa73892.
This reverts commit 7920a7d9.

(cherry picked from commit 50adbd7c)

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

There weas lots of historical cruft to be found here. The `export
SHELLOPTS` breaks on NixOS due to bash syntax in the gcc wrapper script.

Reviewers: hvr

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit 3441b145)

Commit 193664d4 added a
special caseRule for `dataToTag`, but this transformation completely
broke when `dataToTag` was applied to somewith with a type headed by
a data family, leading to #14680. For now at least, the simplest
solution is to simply not apply this transformation when the type is
headed by a data family.

Test Plan: make test TEST=T14680

Reviewers: simonpj, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14680

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

(cherry picked from commit d8a0e6d3)

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

GCC's __sync primitives apparently "usually" imply a full barrier,
meaning they can be used to emulate the more precise C11 atomics albeit
with a loss of efficiency. This restores compatibility with GCC 4.4.

This partially reverts commit 59de2909.

Test Plan: Validate on Centos

Reviewers: hvr, simonmar, trommler

Subscribers: rwbarton, thomie, erikd, carter

GHC Trac Issues: #14244

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

(cherry picked from commit 217e4170)

Reviewers: bgamari

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit fdf518c7)

Alec Theriault authored 7 years ago and Ben Gamari committed 7 years ago

This adds a parser-level switch to have 'LINE' and 'COLUMN'
pragmas lexed into actual tokens (as opposed to updating the
position information in the parser).

'lexTokenStream' is the only place where this option is enabled.

Reviewers: bgamari, alexbiehl, mpickering

Reviewed By: mpickering

Subscribers: alanz, rwbarton, thomie, carter

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

(cherry picked from commit 9a57cfeb)

Alec Theriault authored 7 years ago and Ben Gamari committed 7 years ago

The GHC-side `getNameToInstancesIndex` filters out incorrectly some
instances because it is not aware of what modules are visible. Using
`runTcInteractive` means that `ie_visible` gets initialized to a one
module set containing some dummy GHCi module. This is clearly not the
module set we want to check against to see if a given orphan instance
is visible or not.

In fact, GHC has no way of knowing what we want that module set to be
since it doesn't know ahead of time which modules Haddock is making its
docs for. The fix is just to pass that set in as an argument.

Bumps haddock submodule.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: duog, alexbiehl, rwbarton, thomie, carter

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

(cherry picked from commit a47438e88e685971a81874565f2914043c8233c3)

Looks right to me.

(cherry picked from commit 7d9812e8)

Arguably the warning should just be disabled for this test to eliminate
unnecessary wiggle in the future.

(cherry picked from commit fe6fdf68)

Julian Priestley authored 7 years ago and Ben Gamari committed 7 years ago

When using the :add command in haxlsh/ghci, a module/file that can't
be found is still added to the list of targets, resulting in an error
message for the bad module/file for every subsequent usage of the
command. The add command should verify that the module/file can be
found before adding it to the list of targets.

Also add a ":show targets" command to show the currently added list of
commands, and an ":unadd" command to remove a target.

Test Plan:
Add a new GHCi testcase that checks that :add doesn't remember either
files or modules that could not be found, and that both the new :show
and :unadd commands work as expected.

Reviewers: simonmar, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14676

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

(cherry picked from commit 0bff9e67)

This prevents the register being picked up as a scratch register.
Otherwise the allocator would be free to use it before a call. This
fixes #14619.

Test Plan: ci, repro case on #14619

Reviewers: bgamari, Phyx, erikd, simonmar, RyanGlScott, simonpj

Reviewed By: Phyx, RyanGlScott, simonpj

Subscribers: simonpj, RyanGlScott, Phyx, rwbarton, thomie, carter

GHC Trac Issues: #14619

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

(cherry picked from commit add4e1f1)

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: validate

Reviewers: simonmar, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14725

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

(cherry picked from commit 382c12d1)

I noticed while trying to test against LLVM 5.0 that GHC would throw "Couldn't
figure out linker information" warnings due to LLD being chosen by configure.
Adding detection support to silence these is simple enough, let's just do it.

(cherry picked from commit 6c0db98b)

Trac #14732 was a perpelexing bug in which -fdefer-typed-holes
caused a mysterious type error in a RULE.  This turned out to
be because we are more aggressive about creating implications
when deferring (see TcUnify.implicationNeeded), and the rule
mechanism hadn't caught up.

This fixes it.

(cherry picked from commit e9ae0cae)

We already prioritise equalities when solving, but
Trac #14723 showed that we were not doing so consistently
enough, and as a result the type checker could go into a loop.
Yikes.

See Note [Prioritise equalities] in TcSMonad.

Fixng this bug changed the solve order enough to demonstrate
a problem with fundeps: Trac #14745.

(cherry picked from commit efba0546)

runTcSWithEvBinds does some unification, so the zonkWC
must be after, not before!  Yikes.  An outright bug.

This fixes Trac #14715.

(cherry picked from commit e7c3878d)