GitLab

Summary:
Phab:D907 introduced SourceText for a number of data types, by replacing
FastString with (SourceText,FastString). Since this has an Outputable
instance, no warnings are generated when ppr is called on it, but
unexpected output is generated. See Phab:D1096 for an example of this.

Replace the (SourceText,FastString) tuples with a new data type,
```lang=hs
data StringLiteral = StringLiteral SourceText FastString
```

Update haddock submodule accordingly

Test Plan: ./validate

Reviewers: hvr, austin, rwbarton, trofi, bgamari

Reviewed By: trofi, bgamari

Subscribers: thomie, trofi, rwbarton, mpickering

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

GHC Trac Issues: #10692

Test Plan: validate

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, thomie

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

GHC Trac Issues: #10481

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

Simon Marlow authored Jul 30, 2015 and Simon Marlow committed Jul 31, 2015

Summary:
The fix is a bit clunky, and is perhaps not the best fix, but I'm not
sure how much work it would be to fix it the other way (see comments
for more info).

Test Plan: T7919 doesn't crash

Reviewers: austin, rwbarton, ezyang, bgamari

Subscribers: thomie

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

GHC Trac Issues: #7919

This fixes the FreeBSD build.

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

Needed to get closer to passing `validate --slow`.

Update submodule array.

Test names should be unique. This fixes a framework failure.

I wish Haddock did not fall over when some random non-Haddock comment
contains *'s.  I got

  compiler/rename/RnBinds.hs:732:8: error:
    parse error on input ‘-- *are not* in scope in the SPECIALISE instance pramas; e.g.’

This patch says '-- /are not/ in scope...' to pacify Haddock.

Note: the haddock comment in TyCon.hs seems to be
      garbled syntactically and grammatically

JohnWiegley authored Jul 30, 2015 and Ben Gamari committed Jul 30, 2015

Summary:
Change the error message generated when a deriving clause related to a newtype
fails to always suggested trying GeneralizedNewtypeDeriving, even in
situations where it may not work. Fixes #9600.

Test Plan: testsuite/deriving/should_fail/9600.hs

Reviewers: austin, bgamari, simonpj

Rebased-by: bgamari

Reviewed By: simonpj

Subscribers: bgamari, hvr, simonmar, carter

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

GHC Trac Issues: #9600

Bartosz Nitka authored Jul 30, 2015 and Ben Gamari committed Jul 30, 2015

Test Plan: none

Reviewers: austin, simonmar, bgamari

Reviewed By: simonmar, bgamari

Subscribers: thomie

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

rasen authored Jul 30, 2015 and Ben Gamari committed Jul 30, 2015

Some headers used `new` as parameter name, which is reserved word in
C++. This patch changes these names to `new_`.

Test Plan: validate

Reviewers: austin, ezyang, bgamari, simonmar

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #10700

Tamar Christina authored Jul 30, 2015 and Ben Gamari committed Jul 30, 2015

Currently checking out the source on windows requires two git
checkouts. One for the GHC sources and one for the GHC-tarballs.

This patch will make configure issue an error if compiling under
windows and the GHC-tarballs folder is missing.

On failure the user is told which command they need to run to get the
tarballs or if they want configure to handle it for them configure
provide the `--enable-tarballs-autodownload` flag.

Test Plan:
1. make sure ghc-tarballs folder is not present
2. run ./configure which should fail giving an error that tarballs is
missing and how to get it
3. run ./configure --enable-tarballs-autodownload and the tarballs
should be downloaded and configure finishes
4. rerun the command in 3, no new download should be done.
5. run configure without --enable-tarballs-autodownload, configure
should finish correctly.

Reviewers: bgamari, austin, thomie

Reviewed By: thomie

Subscribers: thomie

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

GHC Trac Issues: #10705

This fixes #9516.

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

Authored-by: Edsko de Vries <edsko@well-typed.com>

These two testsuite files were correct in my build
tree but not in my source tree; apologies.

The provoking cause for this patch is Trac #5001, comment:23.  There
was an INLINE pragma in an instance decl, that shouldn't be there.
But there was no complaint, just a  mysterious WARN later.

I ended up having to do some real refactoring but the result is,
I think, simpler and more robust.

As it stood the main function in the test always returned
bottom, and GHC noticed that and therefore made no attempt
to optimise it, which rather negated the test.

This change makes it non-vacuous.

This patch suppresses them until they are fixed

libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning:
    Rule "parList/rseq" may never fire
      because ‘rseq’ might inline first
    Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘rseq’

libraries/parallel/Control/Parallel/Strategies.hs:582:1: warning:
    Rule "evalBuffer/rseq" may never fire
      because ‘rseq’ might inline first
    Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘rseq’

libraries/parallel/Control/Parallel/Strategies.hs:583:1: warning:
    Rule "parBuffer/rseq" may never fire
      because ‘rseq’ might inline first
    Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘rseq’

In this commit
   commit 0696fc6d
   Author: Simon Peyton Jones <simonpj@microsoft.com>
   Date:   Fri Jun 26 11:40:01 2015 +0100

I made an error in the is_var_scrut tests in extendEnvForProdAlt.

This patch fixes it, thereby fixing Trac #10694.

competesWith is a very recent function, introduced in:

  commit 2d88a531
  Author: Simon Peyton Jones <simonpj@microsoft.com>
  Date:   Fri Jul 24 12:50:42 2015 +0100

      Improve warnings for rules that might not fire

This change avoids a spurious WARNing from mkCast.  In the output of
the desugarer (only, I think) we can have a cast where the type of the
expression and cast don't syntactically match, because of an enclosing
type-let binding.

See Note [Unbound template type variables] in Rules.hs
This fixes Trac #10689.

The problem was a rule LHS that mentioned a type variable
in a phantom argument to a type synonym.  Then matching the
LHS didn't bind the type variable, and the rule matcher
complained.

This patch fixes the problem, as described by the Note.

I also went back to not-cloning the template varaibles during
rule matching.  I'm convinced that it's not necessary now
(if it ever was), and cloning makes the fix for #10689 much more
fiddly.

Test Plan: validate

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, thomie

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

GHC Trac Issues: #10696

Summary:
[Revised version of D1076 that was committed and then backed out]

In a workload with a large amount of code, zero_static_objects_list()
takes a significant amount of time, and furthermore it is in the
single-threaded part of the GC.

This patch uses a slightly fiddly scheme for marking objects on the
static object lists, using a flag in the low 2 bits that flips between
two states to indicate whether an object has been visited during this
GC or not.  We also have to take into account objects that have not
been visited yet, which might appear at any time due to runtime linking.

Test Plan: validate

Reviewers: austin, ezyang, rwbarton, bgamari, thomie

Reviewed By: bgamari, thomie

Subscribers: thomie

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

GHC now warns if rules compete, so that it's not predicatable
which will work and which will not. E.g.

{-# RULES
  f (g x) = ...
  g True  = ...
  #-}

If we had (f (g True)) it's not clear which rule would fire.

This showed up fraility in the libraries.

* Suppress warnigns in Control.Arrow, Control.Category for class
  methods. At the moment we simply don't have a good way to write a
  RULE with a class method in the LHS.  See Trac #1595.  Arrow and
  Category attempt to do so; I have silenced the complaints with
  -fno-warn-inline-rule-shadowing, but it's not a great solution.

* Adjust the NOINLINE pragma on 'GHC.Base.map' to account for the
  map/coerce rule

* Adjust the rewrite rules in Enum, especially for the "literal 1"
  case.  See Note [Enum Integer rules for literal 1].

* Suppress warnings for 'bytestring' e.g.
   libraries/bytestring/Data/ByteString.hs:895:1: warning:
      Rule "ByteString specialise break (x==)" may never fire
        because rule "Class op ==" for ‘==’ might fire first
      Probable fix: add phase [n] or [~n] to the competing rule

the expected error message is from an older version of GHC; I don’t know
the exact error message that we should get here until the bug is
fixed...

This reverts commit b949c96b.

This reverts commit 09d05050.

Two main things here

* Previously we only warned about the "head" function of the rule,
  but actually the warning applies to any free variable on the LHS.

* We now warn not only when one of these free vars can inline, but
  also if it has an active RULE (c.f. Trac #10528)

See Note [Rules and inlining/other rules] in Desugar

This actually shows up quite a few warnings in the libraries, notably
in Control.Arrow, where it correctly points out that rules like
    "compose/arr"   forall f g .
                    (arr f) . (arr g) = arr (f . g)
might never fire, because the rule for 'arr' (dictionary selection)
might fire first.  I'm not really sure what to do here; there is some
discussion in Trac #10595.

A minor change is adding BasicTypes.pprRuleName to pretty-print RuleName.