GitLab

Refactoring only. I compared before and after with 'make slow', and it
still runs each test with the same 'ways' as before.

This fixes #9917.

This allows building ghc in '/ghc'.

This seems necessary after 9634e245 (#11569).

Ticket #11535 dealt with derived Read instances of infix Unicode
value constructors. GHC 7.10.3 used to derive (Read/Show)
instances so that `read . show` for values of such types had no
parse.

The issue has been fixed by other compiler update. This patch
adds only tests, so that derived instance of Read/Show for infix
Unicode value constructors has correct parse, satisfying Haskell
2010 Specification.

Resolves: #11535

Test Plan: `make test TEST=T11535`

Reviewers: austin, rwbarton, thomie, bgamari

Reviewed By: rwbarton, thomie, bgamari

Subscribers: rwbarton, thomie

Projects: #ghc

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

GHC Trac Issues: #11535

The previous test failed for me because I had

    GhcRTSWays += thr_debug_p

in my validate.mk, which doesn't enable profiling by itself.

Originally I planned to make this reference manually managed, but it
looks like at some point I gave it a finalizer on the GHC side, but
forgot to remove the manual free here.  The result is that ghc-iserv
could crash in getStablePtr sometimes when using TH.

In some cases ApplicativeDo would miss some opportunities, due to a
wrong calculation of free variables in RnExpr.segments.

should_compile_flag_nohaddock and should_compile_noflag_nohaddock
contain the exact same tests. By passing `-haddock` to the tests in
should_compile_**flag**_nohaddock, at least they're now testing
different things.

Add documentation.

Refactoring only. Cleanup some loose ends from #10196.

Initially the idea was to only allow modifier letters at the end of
identifiers. Since we later decided to allow modifier letters also in
the middle of identifiers (because not doing so would not fix the
regression completely), the names `suffix` and `okIdSuffixChar` don't
seem appropriate anymore.

Remove TODO. Move test from should_fail to should_compile.

A long time ago, you could use `"-- # <haddock options>"` to mean that
`<haddock options.` should be passed to `haddock`. Since 2007
(03d8585e), using `OPTIONS_HADDOCK` is
the preferred way to do this.

Why is ok to remove support for "-- # .."?

* It is not mentioned in the Haddock user's guide, nor are there any
  tests that use it.

* Ever since 2011 (b3e30449), it doesn't
  actually work anymore. The function `getOptionsFromFile` uses
  `gopt_unset dflags Opt_Haddock` for other reasons, so even when
  running ghc with `--haddock`, the following rule always fires when the
  lexer sees "-- # ..", and it gets treated as a normal comment:

```
    -- Next, match Haddock comments if no -haddock flag
    "-- " [$docsym \#] .* / { ifExtension (not . haddockEnabled) } { lineCommentToken }
```

Reviewed by: bgamari

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

In order to make this work I needed to shuffle around typechecking a bit
such that `TyCon` and friends are available during compilation of
GHC.Types.  I also did a bit of refactoring of `TcTypeable`.

Test Plan: Validate

Reviewers: simonpj, austin

Subscribers: simonpj, thomie

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

GHC Trac Issues: #11120

...when computing the size of a call on the RHS of a type
instance declaration.

This came up in Trac #11581.  The change is in
   TcType.tcTyFamInsts
which now trims the type arguments in a call.  See the
comments with that function definition.

Several things here:

* Re-implement piResultTys so that its substitution has
  the correct in-scope set

  That means paying close attention to performance, since as we
  discovered in Trac #11371, it's a heavily used function and
  is often used on ordinary function types, with no foralls to
  worry about substituting.

* Kill off applyTys, which was just the same as piResultTys.

* Re-engineer MkCore.mkCoreApps so that it calls piResultTys,
  rather than repeatedly calling piResultTy.

No change in functionality here, but greater clarity:

* In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
  We are already maintaining an in-scope set in the fe_subst field,
  so it's silly do to it twice.

  (This isn't strictly connected to the rest of this patch, but
  the nomenclature changes below affect the same code, so I put
  them together.)

* TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
  out what to do, but in fact we almost always know which of the
  two we are doing.  So:
    - define extendTvSubst, extendCvSubst
    - and use them

* Similar renamings in TyCoRep:
   - extendTCvSubstList        -->   extendTvSubstList
   - extendTCvSubstBinder      -->   extendTvSubstBinder
   - extendTCvSubstAndInScope  --> extendTvSubstAndInScope

* Add Type.extendTvSubstWithClone, extendCvSubstWithClone

* Similar nomenclature changes in Subst, SimplEnv, Specialise

* Kill off TyCoRep.substTelescope (never used)

When implementing Strict Haskell, the patch 46a03fbe didn't faithfully
implement the semantics given in the manual. In particular there was
an ad-hoc case in mkSelectorBinds for "strict and no binders" that
didn't work.

This patch fixes it, curing Trac #11572.

Howver it forced me to think about banged let-bindings, and I rather
think we do not have quite the right semantics yet, so I've opened
Trac #11601.

RyanGlScott updated the Diff only after I had merged it.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11590

Currently, `-XDeriveFoldable` and `-XDeriveTraversable` generate
unnecessary `mempty` and `pure` expressions when it traverses of an
argument of a constructor whose type does not mention the last type
parameter. Not only is this inefficient, but it prevents `Traversable`
from being derivable for datatypes with unlifted arguments (see
Trac #11174).

The solution to this problem is to adopt a slight change to the
algorithms for `-XDeriveFoldable` and `-XDeriveTraversable`, which is
described in [this wiki
page](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFu
nctor#Proposal:alternativestrategyforderivingFoldableandTraversable).
The wiki page also describes why we don't apply the same changes to the
algorithm for `-XDeriveFunctor`.

This is techincally a breaking change for users of `-XDeriveFoldable`
and `-XDeriveTraversable`, since if someone was using a law-breaking
`Monoid` instance with a derived `Foldable` instance (i.e., one where `x
<> mempty` does not equal `x`) or a law-breaking `Applicative` instance
with a derived `Traversable` instance, then the new generated code could
result in different behavior. I suspect the number of scenarios like
this is very small, and the onus really should be on those users to fix
up their `Monoid`/`Applicative` instances.

Fixes #11174.

Test Plan: ./validate

Reviewers: hvr, simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11174

The Eq and Ord instance were previously hand-written and this change
updates them to be automatically derived by the compiler.  The derived
behavior should be equivalent to the original.

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Previously, we looked through synonyms when counting arguments,
but that's a bit silly.