GitLab

Summary:
In D2448 (which introduced Template Haskell support for unboxed
sums), I neglected to add `unboxedSumDataName` and `unboxedSumTypeName`
functions, since there wasn't any way you could write unboxed sum data or type
constructors in prefix form to begin with (see #12514). But even if you can't
write these `Name`s directly in source code, it would still be nice to be able
to use these `Name`s in Template Haskell (for instance, to be able to treat
unboxed sum type constructors like any other type constructors).

Along the way, this uncovered a minor bug in `isBuiltInOcc_maybe` in
`TysWiredIn`, which was calculating the arity of unboxed sum data constructors
incorrectly.

Test Plan: make test TEST=T12478_5

Reviewers: osa1, goldfire, austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #12478, #12514

This reverts commit 3a00ff92 due
to #12993

Previously, these functions were hardcoded so as to always `error`
whenever given an argument of 0 or 1. This restriction can be lifted
pretty easily, however.

This requires a slight tweak to `isBuiltInOcc_maybe` in `TysWiredIn` to
allow it to recognize `Unit#` (which is the hard-wired `OccName` for
unboxed 1-tuples).

Fixes #12977.

Test Plan: make test TEST=12977

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #12977

After talking to Richard, he and I concluded that choosing the rather
common name `Newtype` to represent the corresponding deriving strategy
in Template Haskell was a poor choice of name. I've opted to rename it
to something less common (`NewtypeStrategy`) while we still have time. I
also renamed the corrsponding datatype in the GHC internals so as to
match it.

Reviewers: austin, goldfire, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #10598

Summary:
A continuation of #8953. This fixes an oversight in which the
left-hand sides of closed type families, when reified in Template Haskell,
would not be given kind annotations, even when they are necessary for
disambiguation purposes in the presence of `PolyKinds`.

Fixes #8953 and #12646.

Test Plan: ./validate

Reviewers: hvr, bgamari, austin, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #8953, #12646

Summary:
Add prettyprinter tests, which take a file, parse it, pretty print it,
re-parse the pretty printed version and then compare the original and
new ASTs (ignoring locations)

Updates haddock submodule to match the AST changes.

There are three issues outstanding

1. Extra parens around a context are not reproduced. This will require an
   AST change and will be done in a separate patch.

2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
   to prevent noise in the output.

   I am not sure what the desired behaviour in this case is, so have left
   it as before. Test Ppr047 is marked as expected fail for this.

3. Apart from in a context, the ParsedSource AST keeps all the parens from
   the original source.  Something is happening in the renamer to remove the
   parens around visible type application, causing T12530 to fail, as the
   dumped splice decl is after the renamer.

   This needs to be fixed by keeping the parens, but I do not know where they
   are being removed.  I have amended the test to pass, by removing the parens
   in the expected output.

Test Plan: ./validate

Reviewers: goldfire, mpickering, simonpj, bgamari, austin

Reviewed By: simonpj, bgamari

Subscribers: simonpj, goldfire, thomie, mpickering

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

GHC Trac Issues: #3384

Previously TH was incorrectly returning a `Dec` using a `ConT` instead
of `PromotedT`.

Test Plan: validate

Reviewers: mainland, jstolarek, osa1, goldfire, thomie, bollmann,
bgamari, RyanGlScott, austin

Reviewed By: RyanGlScott

Subscribers: erikd

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

GHC Trac Issues: #11629

It turned out that finalizers were run too early and information
resulting from simplifying constraints was not available.

This patch runs finalizers after a first call to simplifyTop, and
then calls simplifyTop a second time to deal with constraints
that could result from running the finalizers.

Fixes T12777

Test Plan: ./validate

Reviewers: goldfire, simonpj, bgamari, austin

Reviewed By: simonpj

Subscribers: mpickering, mboes, thomie

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

GHC Trac Issues: #12777

The comment indicated that scoping of type variables was a large problem
but Simon fixed it in e21e13fb.

Thus, we can implement repP for signatures very easily in the usual way
now.

Reviewers: goldfire, simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: mpickering, simonpj, thomie

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

GHC Trac Issues: #12164

Commit bce99086 (#12584) fixed #12788. Let's
add a test to make sure it stays fixed.

This patch does a raft of useful tidy-ups in the type checker.
I've been meaning to do this for some time, and finally made
time to do it en route to ICFP.

1. Modify TcType.ExpType to make a distinct data type,
   InferResult for the Infer case, and consequential
   refactoring.

2. Define a new function TcUnify.fillInferResult, to fill in
   an InferResult. It uses TcMType.promoteTcType to promote
   the type to the level of the InferResult.
   See TcMType Note [Promoting a type]
   This refactoring is in preparation for an improvement
   to typechecking pattern bindings, coming next.

   I flirted with an elaborate scheme to give better
   higher rank inference, but it was just too complicated.
   See TcMType Note [Promotion and higher rank types]

3. Add to InferResult a new field ir_inst :: Bool to say
   whether or not the type used to fill in the
   InferResult should be deeply instantiated.  See
   TcUnify Note [Deep instantiation of InferResult].

4. Add a TcLevel to SkolemTvs. This will be useful generally

    - it's a fast way to see if the type
      variable escapes when floating (not used yet)

    - it provides a good consistency check when updating a
      unification variable (TcMType.writeMetaTyVarRef, the
      level_check_ok check)

   I originally had another reason (related to the flirting
   in (2), but I left it in because it seems like a step in
   the right direction.

5. Reduce and simplify the plethora of uExpType,
   tcSubType and related functions in TcUnify.  It was
   such an opaque mess and it's still not great, but it's
   better.

6. Simplify the uo_expected field of TypeEqOrigin.  Richard
   had generatlised it to a ExpType, but it was almost always
   a Check type.  Now it's back to being a plain TcType which
   is much, much easier.

7. Improve error messages by refraining from skolemisation when
   it's clear that there's an error: see
   TcUnify Note [Don't skolemise unnecessarily]

8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
   so I added it

9. Kill off tcs_used_tcvs.  Its purpose is to track the
   givens used by wanted constraints.  For dictionaries etc
   we do that via the free vars of the /bindings/ in the
   implication constraint ic_binds.  But for coercions we
   just do update-in-place in the type, rather than
   generating a binding.  So we need something analogous to
   bindings, to track what coercions we have added.

   That was the purpose of tcs_used_tcvs.  But it only
   worked for a /single/ iteration, whereas we may have
   multiple iterations of solving an implication.  Look
   at (the old) 'setImplicationStatus'.  If the constraint
   is unsolved, it just drops the used_tvs on the floor.
   If it becomes solved next time round, we'll pick up
   coercions used in that round, but ignore ones used in
   the first round.

   There was an outright bug.  Result = (potentialy) bogus
   unused-constraint errors.  Constructing a case where this
   actually happens seems quite trick so I did not do so.

   Solution: expand EvBindsVar to include the (free vars of
   the) coercions, so that the coercions are tracked in
   essentially the same way as the bindings.

   This turned out to be much simpler.  Less code, more
   correct.

10. Make the ic_binds field in an implication have type
      ic_binds :: EvBindsVar
    instead of (as previously)
       ic_binds :: Maybe EvBindsVar
    This is notably simpler, and faster to use -- less
    testing of the Maybe.  But in the occaional situation
    where we don't have anywhere to put the bindings, the
    belt-and-braces error check is lost.  So I put it back
    as an ASSERT in 'setImplicationStatus' (see the use of
    'termEvidenceAllowed')

All these changes led to quite bit of error message wibbling

The fix for #12584 also fixed the problem in #12411. Let's add a test to ensure
that it stays fixed.

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

Allows users to explicitly request which approach to `deriving` to use
via keywords, e.g.,

```
newtype Foo = Foo Bar
  deriving Eq
  deriving stock    Ord
  deriving newtype Show
```

Fixes #10598. Updates haddock submodule.

Test Plan: ./validate

Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
erikd, simonmar

Reviewed By: alanz, bgamari, simonpj

Subscribers: thomie, mpickering, oerjan

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

GHC Trac Issues: #10598

Summary:
Module finalizer could call addTopDecls, however, the declarations
added in this fashion were ignored. This patch makes sure to rename,
type check and incorporate this declarations.

Because a declaration may include a splice which calls addModFinalizer,
the list of finalizers is repeteadly checked after adding declarations
until no more finalizers remain.

Test Plan: ./validate

Reviewers: bgamari, goldfire, simonpj, austin

Reviewed By: bgamari, simonpj

Subscribers: simonmar, mboes, thomie

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

GHC Trac Issues: #12559

Summary: Fixes #12530.

Test Plan: make test TEST=12530

Reviewers: austin, bgamari, hvr, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #12530

This adds new constructors `UnboxedSumE`, `UnboxedSumT`, and
`UnboxedSumP` to represent unboxed sums in Template Haskell.

One thing you can't currently do is, e.g., `reify ''(#||#)`, since I
don't believe unboxed sum type/data constructors can be written in
prefix form.  I will look at fixing that as part of #12514.

Fixes #12478.

Test Plan: make test TEST=T12478_{1,2,3}

Reviewers: osa1, goldfire, austin, bgamari

Reviewed By: goldfire, bgamari

Subscribers: thomie

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

GHC Trac Issues: #12478

Summary:
Previously, TH would implicitly remove the parentheses when splicing in
singleton unboxed tuple types (e.g., turning `(# Int #)` into `Int`). Luckily,
the fix is simply to delete some code.

Fixes #12513.

Test Plan: make test TEST=T12513

Reviewers: hvr, bgamari, austin, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #12513

Summary:
`okConIdOcc`, which validates that a type or constructor name is valid
for splicing using Template Haskell, has a special case for tuples, but
neglects to look for unboxed tuples, causing some sensible Template Haskell
code involving unboxed tuples to be rejected.

Fixes #12407.

Test Plan: make test TEST=T12407

Reviewers: austin, bgamari, hvr, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #12407

Summary:
Previously, Template Haskell reified unboxed tuple types as boxed
tuples with twice the appropriate arity.

Fixes #12403.

Test Plan: make test TEST=T12403

Reviewers: hvr, goldfire, austin, bgamari

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #12403

Summary:
This annotates the splice point with 'HsSpliced ref e' where 'e' is the
result of the splice. 'ref' is a reference that the typechecker will fill with
the local type environment.

The finalizer then reads the ref and uses the local type environment, which
causes 'reify' to find local variables when run in the finalizer.

Test Plan: ./validate

Reviewers: simonpj, simonmar, bgamari, austin, goldfire

Reviewed By: goldfire

Subscribers: simonmar, thomie, mboes

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

GHC Trac Issues: #11832

Summary:
T8761 seems to get different interleaving in its output on
Phabricator, so this switches it to use stderr consistently.

Test Plan: worksforme

Reviewers: goldfire, austin, bgamari, erikd

Subscribers: thomie

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

* Set config settings directly in mk/test.mk, instead of indirectly in
  config/ghc
* passing --hpcdir for WAY=hpc is unnecessary

When using TH to splice expressions involving record field construction,
the parent datacon may not be in scope.  We shouldn't panic about this,
because we will be renaming Exact RdrNames which don't require any
disambiguation.

Test Plan: new test th/T12130

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #12130

This major commit was initially triggered by #11339, but it spiraled
into a major review of the way in which type signatures for bindings
are handled, especially partial type signatures.  On the way I fixed a
number of other bugs, namely
   #12069
   #12033
   #11700
   #11339
   #11670

The main change is that I completely reorganised the way in which type
signatures in bindings are handled. The new story is in TcSigs
Note [Overview of type signatures].  Some specific:

* Changes in the data types for signatures in TcRnTypes:
  TcIdSigInfo and new TcIdSigInst

* New module TcSigs deals with typechecking type signatures
  and pragmas. It contains code mostly moved from TcBinds,
  which is already too big

* HsTypes: I swapped the nesting of HsWildCardBndrs
  and HsImplicitBndsrs, so that the wildcards are on the
  oustide not the insidde in a LHsSigWcType.  This is just
  a matter of convenient, nothing deep.

There are a host of other changes as knock-on effects, and
it all took FAR longer than I anticipated :-).  But it is
a significant improvement, I think.

Lots of error messages changed slightly, some just variants but
some modest improvements.

New tests

* typecheck/should_compile
    * SigTyVars: a scoped-tyvar test
    * ExPat, ExPatFail: existential pattern bindings
    * T12069
    * T11700
    * T11339

* partial-sigs/should_compile
    * T12033
    * T11339a
    * T11670

One thing to check:

* Small change to output from ghc-api/landmines.
  Need to check with Alan Zimmerman

Summary:
MatchFixity was introduced to facilitate use of API Annotations.

HsMatchContext does the same thing with more detail, but is chased
through all over the place to provide context when processing a Match.

Since we already have MatchFixity in the Match, it may as well provide
the full context.

updates submodule haddock

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #12105

(cherry picked from commit 306ecad5)

Refactoring only.

Change help message so it doesn't specify -auto-all.
Make old profiling flags deprecated as they are no longer
documented.
Update Makefile and documentation accordingly.
Update release notes for ghc 8.2

Test Plan:
./verify; `ghc --help` shouldn't specify the -auto-all
flag. Furthermore `ghc -fprof -auto-all` should emit a warning

Reviewed By: thomie, austin

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

GHC Trac Issues: #12084

Update submodule nofib

This creates a new package, `ghc-boot-th`, to contain the `Extension`
type, which now lives in `GHC.LanguageExtension.Type`. This ensures that
the transitive dependency set of the `template-haskell` package remains
minimal.

The `GHC.LanguageExtensions.Type` module is also re-exported by
`ghc-boot`, which provides an orphan `binary` instance as well.

Test Plan: Validate

Reviewers: goldfire, thomie, hvr, austin

Reviewed By: thomie

Subscribers: RyanGlScott, thomie, erikd, ezyang

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

This commit adds Template Haskell support for pattern synonyms as
requested by trac ticket #8761.

Test Plan: ./validate

Reviewers: thomie, jstolarek, osa1, RyanGlScott, mpickering, austin,
goldfire, bgamari

Reviewed By: goldfire, bgamari

Subscribers: rdragon

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

GHC Trac Issues: #8761

"One fewer arguments to ..." rather than
"One fewer argument to ..."

Trac #11941 demonstrated a case where an out-of-scope error also
gave rise to a (bogus and confusing) stage restriction message.

It's caused by the fact that out-of-scope errors do not stop
renaming, but rather return an "unbound name".  We need to
detect this in the stage-restriction test to avoid the double
error.  Easy fix.