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)

Currently, error messages that germane to GADT constructors
put the source span at only the first character in the constructor,
leading to insufficient caret diagnostics. This can be easily fixed
by using a source span that spans the entire constructor, instead of
just the first character.

Test Plan: make test TEST=T14719

Reviewers: alanz, bgamari, simonpj

Reviewed By: alanz, simonpj

Subscribers: simonpj, goldfire, rwbarton, thomie, carter

GHC Trac Issues: #14719

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

(cherry picked from commit 59fa7b32)

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

On Windows we use the function `win32AllocStack` to do stack
allocations in 4k blocks and insert a stack check afterwards
to ensure the allocation returned a valid block.

The problem is this function does something that by C semantics
is pointless. The stack allocated value can never escape the
function, and the stack isn't used so the compiler just optimizes
away the entire function body.

After considering a bunch of other possibilities I think the simplest
fix is to just disable optimizations for the function.

Alternatively inline assembly is an option but the stack check function
doesn't have a very portable name as it relies on e.g. `libgcc`.

Thanks to Sergey Vinokurov for helping diagnose and test.

Test Plan: ./validate

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14669

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

(cherry picked from commit a55d581f)

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

This is an obvious optimisation whose overhead is neglectable but
which significantly simplifies the common uses of `compareByteArrays#`
which would otherwise require to make *careful* use of
`reallyUnsafePtrEquality#` or (equally fragile) `byteArrayContents#`
which can result in less optimal assembler code being generated.

Test Plan: carefully examined generated cmm/asm code; validate via phab

Reviewers: alexbiehl, bgamari, simonmar

Reviewed By: bgamari, simonmar

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit 31c260f3)

A silly mistake in `gen_Show_binds` was causing derived
`Show` instances for empty data types to case on the precedence
argument instead of the actual value being showed.

Test Plan: make test TEST=drv-empty-data

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14692

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

(cherry picked from commit 0074a08e)

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

This adds support for the bit deposit and extraction operations provided
by the BMI and BMI2 instruction set extensions on modern amd64 machines.

Implement x86 code generator for pdep and pext.  Properly initialise
bmiVersion field.

pdep and pext test cases

Fix pattern match for pdep and pext instructions

Fix build of pdep and pext code for 32-bit architectures

Test Plan: Validate

Reviewers: austin, simonmar, bgamari, angerman

Reviewed By: bgamari

Subscribers: trommler, carter, angerman, thomie, rwbarton, newhoggy

GHC Trac Issues: #14206

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

(cherry picked from commit f8557696)

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

This is an attempt at clarifying the docs for HasCallStack in both the
user guide and libraries/base/GHC/Stack/Types.hs. The example used right
now is built around an hypothetical 'error' function that doesn't itself
print call stacks, and the fact that this doesn't hold makes it all
confusing, see #14635.

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14635

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

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

- Cabal-2.2 uses SPDX license identifiers, so I had to update
  `cabal-version: 2.1` packages `license: BSD3` to
  `license: BSD-3-Clause`
- `ghc-cabal` used old ReadP parsec, now it uses `parsec` too
- InstalledPackageInfo pretty-printing have changed a little,
  fields with default values aren't printed. This can be changed in
  `Cabal` still, but I haven't found problems with omitting them.

Note: `BSD-3-Clause` is parsed as "name = BSD, version = 3" by old
parser (because 3-Clause looks like version 3 with tag Clause).
If you see *"BSD-3" is not a valid license*, then something is using
old parser still.

Fixes #9885.

(cherry picked from commit 5d6e0806c690ac1958e4cbf609bc6b18048fb761)

It turns out that `Convert` was recklessly leaving off
parentheses in two places:

* Negative numeric literals
* Patterns in lambda position

This patch fixes it by adding three new functions, `isCompoundHsLit`,
`isCompoundHsOverLit`, and `isCompoundPat`, and using them in the
right places in `Convert`. While I was in town, I also sprinkled
`isCompoundPat` among some `Pat`-constructing functions in `HsUtils`
to help avoid the likelihood of this problem happening in other
places. One of these places is in `TcGenDeriv`, and sprinkling
`isCompountPat` there fixes #14682

Test Plan: make test TEST="T14681 T14682"

Reviewers: alanz, goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14681, #14682

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

(cherry picked from commit 575c009d)

On Windows GHC enforces currently that the real executable is named
ghc.exe/ghc-stage[123].exe.

I don't see a good reason why this is neccessary.
This patch removes this restriction and fixes #14652

Test Plan: ci

Reviewers: bgamari, Phyx

Reviewed By: Phyx

Subscribers: Phyx, rwbarton, thomie, carter

GHC Trac Issues: #14652

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

(cherry picked from commit 1bf70b20)

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14653

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

(cherry picked from commit 2feed118)

Matthías Páll Gissurarson authored 7 years ago and Ben Gamari committed 7 years ago

This implements SPJ's suggestion on the ticket (#14273). We find the
relevant constraints (ones that whose free unification variables are all
mentioned in the type of the hole), and then clone the free unification
variables of the hole and the relevant constraints. We then add a
subsumption constraints and run the simplifier, and then check whether
all the constraints were solved.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie, carter

GHC Trac Issues: #14273

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

(cherry picked from commit 1e14fd3e)

Previously, GHC was pretty-printing left-section holes
incorrectly and not parsing right-sectioned holes at all. This patch
fixes both problems.

Test Plan: make test TEST=T14590

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #14590

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

(cherry picked from commit 4d41e921)

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

Test Plan: validate

Reviewers: bgamari, niteria, erikd, dfeuer

Reviewed By: dfeuer

Subscribers: Yuras, dfeuer, rwbarton, thomie, carter

GHC Trac Issues: #14497

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

(cherry picked from commit fb1f0a46)

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

Substitute RanlibCmd for consistency, and other configure cleanups that
should have no effect

The other commands are so substituted. Maybe we don't need ranlib at
all, and the configure snippet can be removed all together, but that
can always be done later.

Reviewers: bgamari, hvr, angerman

Reviewed By: bgamari, angerman

Subscribers: rwbarton, thomie, erikd, carter

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

(cherry picked from commit 8de89305)

Trac #14646 happened because we forgot to parenthesize `forall` types to
the left of an arrow. This simple patch fixes that.

Test Plan: make test TEST=T14646

Reviewers: alanz, goldfire, bgamari

Reviewed By: alanz

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14646

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

(cherry picked from commit f380115c)

This patch moves the "ok_unfolding" test
   from  CoreOpt.joinPointBinding_maybe
   to    OccurAnal.decideJoinPointHood

Previously the occurrence analyser was deciding to make
something a join point, but the simplifier was reversing
that decision, which made the decision about /other/ bindings
invalid.

Fixes Trac #14650.

(cherry picked from commit 66ff794f)

This is a pure refactoring.  Use HsConDetails to implement
HsPatSynDetails, instead of defining a whole new data type.
Less code, fewer types, all good.

(cherry picked from commit 584cbd4a)

This recent patch
    commit 1577908f
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Tue Jan 9 16:20:46 2018 +0000

        Fix two more bugs in partial signatures

        These were shown up by Trac #14643

failed validation for typecheck/should_run/T10846
(Reported in Trac #14658.)

The fix is simple.

(cherry picked from commit f3f90a07)

These were shown up by Trac #14643

Bug 1: if we had a single partial signature for
two functions
   f, g :: forall a. _ -> a
then we made two different SigTvs but with the sane Name.
This was jolly confusing and ultimately led to deeply bogus
results with Any's appearing in the resulting program. Yikes.
Fix: clone the quantified variables in TcSigs.tcInstSig (as
indeed its name suggests).

Bug 2: we were not eliminating duplicate/superclass constraints
in the partial signatures of a mutually recursive group.

Easy to fix: we are already doing dup/superclass elim in
TcSimplify.decideQuantification.  So we move the partial-sig
constraints there too.

(cherry picked from commit 1577908f)

This adds a regression test for the original program in #14040.

This does not fix #14040 entirely, though, as the program in
https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2 still
panics, so there is more work to be done there.

(cherry picked from commit be1ca0e4)

Trac #13032 pointed out that we sometimes generate unused
bindings for Givens, and (worse still) we can't always discard
them later (we don't drop a case binding unless we can prove
that the scrutinee is non-bottom.

It looks as if this may be a major reason for the performace
problems in #14338 (see comment:29).

This patch fixes the problem at source, by pruning away all the
dead Givens.  See Note [Delete dead Given evidence bindings]

Remarkably, compiler allocation falls by 23% in
perf/compiler/T12227!

I have not confirmed whether this change actualy helps with

(cherry picked from commit 954cbc7c)

This rather subtle patch fixes Trac #14584.  The problem was
that we'd allowed a coercion, bound in a nested scope, to escape
into an outer scope.

The main changes are

* TcSimplify.floatEqualities takes more care when floating
  equalities to make sure we don't float one out that mentions
  a locally-bound coercion.
  See Note [What prevents a constraint from floating]

* TcSimplify.emitResidualConstraints (which emits the residual
  constraints in simplifyInfer) now avoids burying the constraints
  for escaping CoVars inside the implication constraint.

* Since I had do to this stuff with CoVars, I moved the
  fancy footwork about not quantifying over CoVars from
  TcMType.quantifyTyVars to its caller
  TcSimplify.decideQuantifiedTyVars.  I think its other
  callers don't need to worry about all this CoVar stuff.

This turned out to be surprisigly tricky, and took me a solid
day to get right.  I think the result is reasonably neat, though,
and well documented with Notes.

(cherry picked from commit f5cf9d1a)

In fixing Trac #14584 I found that it would be /much/ more
convenient if a "hole" in a coercion (much like a unification
variable in a type) acutally had a CoVar associated with it
rather than just a Unique.  Then I can ask what the free variables
of a coercion is, and get a set of CoVars including those
as-yet-un-filled in holes.

Once that is done, it makes no sense to stuff coercion holes
inside UnivCo.  They were there before so we could know the
kind and role of a "hole" coercion, but once there is a CoVar
we can get that info from the CoVar.  So I removed HoleProv
from UnivCoProvenance and added HoleCo to Coercion.

In summary:

* Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance

* Similarly in IfaceCoercion

* Make CoercionHole have a CoVar in it, not a Unique

* Make tyCoVarsOfCo return the free coercion-hole variables
  as well as the ordinary free CoVars.  Similarly, remember
  to zonk the CoVar in a CoercionHole

We could go further, and remove CoercionHole as a distinct type
altogther, just collapsing it into HoleCo.  But I have not done
that yet.

(cherry picked from commit a492af06)

This fixes Trac #14479.  Not difficult.

See Note [Quantification and partial signatures] Wrinkle 4,
in TcSimplify.

(cherry picked from commit 72938f58)

This patch fixes two bugs in the treatment of SigTvs at the
kind level:

- We should always generalise them, never default them
  (Trac #14555, #14563)

- We should check if they get unified with each other
  (Trac #11203)

Both are described in TcHsType
   Note [Kind generalisation and SigTvs]

(cherry picked from commit 8361b2c5)

This refactoring

* Renames kcHsTyVarBndrs to kcLHsQTyVars,
  which is more truthful. It is only used in getInitialKind.

* Pulls out bind_telescope from that function, and calls it
  kcLHsTyVarBndrs, again to reflect its argument

* Uses the new kcLHsTyVarBndrs in kcConDecl, where the old
  function was wild overkill.

There should not be any change in behaviour

(cherry picked from commit de204409)

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

when read notifications are requested, too (#13903)

Signed-off-by: Matthias Treydte <mt@waldheinz.de>

KQueue: Drop Bits/FiniteBits instances for Filter as they are really
constants whose bits should not be fiddled with

Signed-off-by: Matthias Treydte <mt@waldheinz.de>

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: gridaphobe, kazu_yamamoto, rwbarton, thomie

GHC Trac Issues: #13903

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

(cherry picked from commit 6c3eafb3)