In deriving for Data, we make some auxiliary functions, but they
didn't always get distinct names (Trac #12245).  This patch fixes
it by using the same mechanism as for dictionary functions, namely
chooseUniqueOccTc.

Some assocated refactoring came along for the ride.

This makes sure that we don't introduce unnecessary
nondeterminism from vectorization.

Also updates dph submodule to reflect the change in types.

GHC Trac: #4012

Fixes Trac #7497 and #12151.   In some earlier upheaval I introduced
a bug in the ambiguity check for genreric-default method.

This patch fixes it.  But in fixing it I realised that the
sourc-location of any such error message was bogus, so I fixed
that too, which involved a slightly wider change; see the
comments with TcMethInfo.

I was able to hide the nondeterminism in some specialized
function, which I believe will be useful in other places.

GHC Trac: #4012

This reverts commit 63777579.

This reverts commit 01f449f4.

Ben Gamari authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: Validate, verify fusion

Reviewers: austin, hvr

Subscribers: thomie

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

GHC Trac Issues: #12354

Ben Gamari authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: Validate

Reviewers: austin

Subscribers: thomie

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

This was introduced by a cut-and-paste error.

seraphime authored 8 years ago and Ben Gamari committed 8 years ago

Fixes issue T12165 by banning duplicate pattern synonyms
signatures. This seems to me the best solution because:

   1) it is coherent with the way we treat other duplicate signatures

   2) the typechecker currently doesn't try to apply a second
       signature to a pattern to see if it matches, probably because
       it assumes there is no more than one signature per object.

Test Plan: ./validate

Reviewers: goldfire, austin, mpickering, bgamari

Reviewed By: mpickering, bgamari

Subscribers: mpickering, thomie

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

GHC Trac Issues: #12165

Ben Gamari authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: Validate

Reviewers: austin, osa1

Reviewed By: osa1

Subscribers: thomie

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

GHC Trac Issues: #12355

GHC Trac: #4012

This documents nondeterminism in code generation and removes
the nondeterministic ufmToList function. In the future someone
will have to use nonDetEltsUFM (with proper explanation)
or pprUFM.

Summary:
This field is never set, but it was being tested and used to decide
whether to resolve an object or not.  This caused non-deterministic
crashes when using the RTS linker (see #12230).

I suspect this is not the correct fix, but putting it up so that Phyx
can tell us what the right fix should be.

Test Plan: validate

Reviewers: austin, Phyx, bgamari, erikd

Subscribers: erikd, thomie, ezyang

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

GHC Trac Issues: #12230

Markus Rothe authored 8 years ago and Ben Gamari committed 8 years ago

This avoids the interactive prompt of xelatex on error.

Matthew Pickering authored 8 years ago and Ben Gamari committed 8 years ago

This makes pattern synonym signatures more consistent with normal
type signatures.

Updates haddock submodule.

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

Fixes #12343.

Testcase: `LC_ALL=C make -C utils/checkUniques`. Works with python2 and
python3.

Reviewed by: bgamari

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

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

Test Plan: validate

Reviewers: austin, bgamari, simonmar

Reviewed By: bgamari, simonmar

Subscribers: thomie

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

Ben Gamari authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: Validate, try tests in ticket

Reviewers: austin

Subscribers: thomie

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

GHC Trac Issues: #12194

Ben Gamari authored 8 years ago and Ben Gamari committed 8 years ago

Previously the flag was silently ignored due the #7679 and #8657. This,
however, seems unnecessarily brutal and makes experimentation unduly
difficult for users.

Test Plan: Validate

Reviewers: austin, simonmar

Subscribers: thomie

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

GHC Trac Issues: #7679, #8657

Summary: Fixes T11554

Reviewers: goldfire, thomie, simonpj, austin, bgamari

Reviewed By: thomie, simonpj, bgamari

Subscribers: simonpj, goldfire, thomie

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

GHC Trac Issues: #11554

Specifically per-component macros and multiple libraries.

Contains Cabal submodule update.

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

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: austin, bgamari

Subscribers: hvr, thomie

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

Summary:
This commit removes the information about whether or not
a TyCon is "recursive", as well as the code responsible
for calculating this information.

The original trigger for this change was complexity regarding
how we computed the RecFlag for hs-boot files.  The problem
is that in order to determine if a TyCon is recursive or
not, we need to determine if it was defined in an hs-boot
file (if so, we conservatively assume that it is recursive.)

It turns that doing this is quite tricky.  The "obvious"
strategy is to typecheck the hi-boot file (since we are
eventually going to need the typechecked types to check
if we properly implemented the hi-boot file) and just extract
the names of all defined TyCons from the ModDetails, but
this actually does not work well if Names from the hi-boot
file are being knot-tied via if_rec_types: the "extraction"
process will force thunks, which will force the typechecking
process earlier than we have actually defined the types
locally.

Rather than work around all this trickiness (it certainly
can be worked around, either by making interface loading
MORE lazy, or just reading of the set of defined TyCons
directly from the ModIface), we instead opted to excise
the source of the problem, the RecFlag.

For one, it is not clear if the RecFlag even makes sense,
in the presence of higher-orderness:

    data T f a = MkT (f a)

T doesn't look recursive, but if we instantiate f with T,
then it very well is!  It was all very shaky.

So we just don't bother anymore.  This has two user-visible
implications:

1. is_too_recursive now assumes that all TyCons are
recursive and will bail out in a way that is still mysterious
to me if there are too many TyCons.

2. checkRecTc, which is used when stripping newtypes to
get to representation, also assumes all TyCons are
recursive, and will stop running if we hit the limit.

The biggest risk for this patch is that we specialize less
than we used to; however, the codeGen tests still seem to
be passing.

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

Reviewers: simonpj, austin, bgamari

Subscribers: goldfire, thomie

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

This documents nondeterminism in code generation and removes
the nondeterministic ufmToList function. In the future someone
will have to use nonDetUFMToList (with proper explanation)
or pprUFMWithKeys.

This directory structure makes it easier to find the tests

This is one of the testcases that I forgot to commit

Ord Unique can be a source of invisible, accidental
nondeterminism as explained in Note [No Ord for Unique].
This removes it, leaving a note with rationale.

It's unfortunate that I had to write Ord instances for
codegen data structures by hand, but I believe that it's a
right trade-off here.

Test Plan: ./validate

Reviewers: simonmar, austin, bgamari

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #4012

The cause of #12213 is in dump_stdout and dump_stderr:

      print(read_no_crs(<filename>))

Commit 6f6f5154 changed read_no_crs to
return a unicode string. Printing a unicode strings works fine as long
as sys.stdout.encoding is 'UTF-8'.

There are two reasons why sys.stdout.encoding might not be 'UTF-8'.

* When output is going to a file, sys.stdout and sys.stdout do not respect
  the locale:

  $ LC_ALL=en_US.utf8 python -c 'import sys; print(sys.stderr.encoding)'
  UTF-8
  $ LC_ALL=en_US.utf8 python -c 'import sys; print(sys.stderr.encoding)' 2>/dev/null
  None

* When output is going to the terminal, explicitly reopening sys.stdout has
  the side-effect of changing sys.stdout.encoding from 'UTF-8' to 'None'.

      sys.stdout = os.fdopen(sys.__stdout__.fileno(), "w", 0)

  We currently do this to set a buffersize of 0 (the actual
  buffersize used is irrelevant for the sys.stdout.encoding problem).

Solution: fix dump_stdout and dump_stderr to not use read_no_crs.

As Trac #12242 showed, there was a missing case in
the pretty printer for IfaceCo. I've refactored it
so that the pattern-match ovelap checker will spot
it next time.