GitLab

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

* 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 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

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.

Reviewers: hvr, goldfire, austin, RyanGlScott, bgamari

Reviewed By: RyanGlScott, bgamari

Subscribers: RyanGlScott, thomie

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

DsMeta curiously omitted quantified tyvars in certain circumstances.
This patch means it doesn't.

Test case: th/T11797

Previously, all kind arguments were being reified, which would cause
something like this:

```
type Id a = a
data Proxy (a :: Id k) = Proxy
```

to output

```
data Proxy (a :: Id * k) = Proxy
```

when `Proxy`'s `Info` is reified. The fix is simple: simply call
`filterOutInvisibleTypes` on the kind arguments of a kind synonym
application.

Fixes #11463.

Test Plan: ./validate

Reviewers: austin, bgamari, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #11463

When the typechecker generates the error message for an out-of-scope
variable, it now uses the GlobalRdrEnv with respect to which the
variable is unbound, not the GlobalRdrEnv which is available at the time
the error is reported.  Doing so ensures we do not provide suggestions
which themselves are out-of-scope (because they are bound in a later
inter-splice group).

Nonetheless, we do note in the error message if an unambiguous, exact
match to the out-of-scope variable is found in a later inter-splice
group, and we specify where that match is not in scope.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #11680

Record selectors of data types spliced in with Template Haskell are not
renamer-resolved correctly in GHC HEAD. The culprit is
`newRecordSelector` which violates notes `Note [Binders in Template
Haskell] in Convert.hs` and `Note [Looking up Exact RdrNames] in
RnEnv.hs`. This commit fixes `newRecordSelector` accordingly.

Test Plan: ./validate

Reviewers: thomie, mpickering, bgamari, austin, simonpj, goldfire

Reviewed By: goldfire

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

GHC Trac Issues: #11809

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11145

The original TH failure observed by the ticket, namely that Template
Haskell quotes of data instance GADTs are broken, is not observable
anymore in HEAD. I therefore just added the corresponding regression
test.

Test Plan: ./validate

Reviewers: goldfire, austin, thomie, jstolarek, bgamari

Reviewed By: bgamari

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

GHC Trac Issues: #11145

Refactoring only.

Since we're not consisently keeping track of which tests should pass
with which compiler versions, there is no point in keeping these
functions.

Update submodules containers, hpc and stm.

The bug itself has already been fixed in #10734, so this
only adds another regression test (as given in the ticket).

Test Plan: ./validate

Reviewers: goldfire, austin, thomie, bgamari

Reviewed By: bgamari

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

GHC Trac Issues: #9022

The idea here is described in [wiki:Typechecker]. Briefly,
this refactor keeps solid track of "synthesis" mode vs
"checking" in GHC's bidirectional type-checking algorithm.
When in synthesis mode, the expected type is just an IORef
to write to.

In addition, this patch does a significant reworking of
RebindableSyntax, allowing much more freedom in the types
of the rebindable operators. For example, we can now have
`negate :: Int -> Bool` and
`(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
is in tcSyntaxOp.

This addresses tickets #11397, #11452, and #11458.

Tests:
  typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
  th/T11452

* T2552 (#10037) is failng for all threaded opt_ways, not for WAY=prof.
* TH_spliceE5_prof (#11495) is failing when ghc_dynamic
* Rename ghci_dynamic to ghc_dynamic. It's the same thing.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Subscribers: goldfire, osa1, thomie

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

GHC Trac Issues: #10603

This is the second (and hopefully last) fix needed to make TH handle
GADTs properly (after D1465). This Diff addresses some issues with infix
GADT constructors, specifically:

* Before, you could not determine if a GADT constructor was declared
  infix because TH did not give you the ability to determine if there is
  a //user-specified// fixity declaration for that constructor. The
  return type of `reifyFixity` was changed to `Maybe Fixity` so that it
  yields `Just` the fixity is there is a fixity declaration, and
  `Nothing` otherwise (indicating it has `defaultFixity`).
* `DsMeta`/`Convert` were changed so that infix GADT constructors are
  turned into `GadtC`, not `InfixC` (which should be reserved for
  Haskell98 datatype declarations).
* Some minor fixes to the TH pretty-printer so that infix GADT
  constructors will be parenthesized in GADT signatures.

Fixes #11345.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari, jstolarek

Reviewed By: jstolarek

Subscribers: thomie

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

GHC Trac Issues: #11345

Previous representation of GADTs in TH was not expressive enough
to express possible GADT return types. See #11341

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Subscribers: thomie, RyanGlScott

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

GHC Trac Issues: #11341

In order to simplify the task, the version munging logic has
been radically simplified:

Previously, in cases where the version contained dates as version components,
the build-system would munge the version of the stage1 ghc package before
registering the `ghc` package.

However, this hack was already questionable at the time of its introduction
(c.f. 7b45c46c).
Simplifying the build-systems by avoiding such hacks may also help the
shaking-up-ghc effort.

So now we simply munge directly via the `.cabal` files, which gives a simpler
picture, as now every stage is munged the same. Munging is only active when
the first patch-level version component is a date. So stable snapshots and release
candidates are unaffacted (as those have the date in the second patch-level
version component)

Reviewers: simonmar, bgamari, austin, thomie, ezyang

Reviewed By: bgamari, thomie, ezyang

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

Happily, the fix is simply deleting some old code. I love it when
that happens.

When compiler_debugged only. This makes the Travis build green again.

Given:
 * `file = "foo.a.b"`
 * `osuf = ".a.b"`  -- Note the initial dot.
 * `new_osuf = "c"`

Before (bad, the last character of the filename is dropped):
  `dropTail (length osuf + 1) file <.> new_osuf == "fo.c"`
After (good):
  `stripExtension osuf file <.> new_osuf` == "foo.c"

This regression was introduced in commit c489af73 (#5554). That commit
fixed a similar but different bug, and care has been taken to not
reintroduce it (using the the newly introduced
`System.Filepath.stripExtension`).

Given:
 * `file = "foo.a.b"`
 * `osuf = "a.b"`
 * `new_osuf = "c"`

Before c489af73 (bad, the full suffix should get replaced):
  `replaceExtension file new_osuf == "foo.a.c"`
After c489af73 (good):
  `dropTail (length osuf + 1) file <.> new_osuf == "foo.c"`
After this commit (still good):
  `stripExtension osuf file <.> new_osuf == "foo.c"`

Reviewed by: bgamari

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

GHC Trac Issues: #9760

Currently, Template Haskell's treatment of strictness is not enough to
cover all possible combinations of unpackedness and strictness. In
addition, it isn't equipped to deal with new features (such as
`-XStrictData`) which can change a datatype's fields' strictness during
compilation.

To address this, I replaced TH's `Strict` datatype with
`SourceUnpackedness` and `SourceStrictness` (which give the programmer a
more complete toolkit to configure a datatype field's strictness than
just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to
reify a constructor fields' strictness post-compilation through the
`reifyConStrictness` function.

Fixes #10697.

Test Plan: ./validate

Reviewers: simonpj, goldfire, bgamari, austin

Reviewed By: goldfire, bgamari

Subscribers: thomie

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

GHC Trac Issues: #10697

Until now GADTs were supported in Template Haskell by encoding them using
normal data types.  This patch adds proper support for representing GADTs
in TH.

Test Plan: T10828

Reviewers: goldfire, austin, bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #10828

Summary:
(Apologies for the size of this patch, I couldn't make a smaller one
that was validate-clean and also made sense independently)

(Some of this code is derived from GHCJS.)

This commit adds support for running interpreted code (for GHCi and
TemplateHaskell) in a separate process.  The functionality is
experimental, so for now it is off by default and enabled by the flag
-fexternal-interpreter.

Reaosns we want this:

* compiling Template Haskell code with -prof does not require
  building the code without -prof first

* when GHC itself is profiled, it can interpret unprofiled code, and
  the same applies to dynamic linking.  We would no longer need to
  force -dynamic-too with TemplateHaskell, and we can load ordinary
  objects into a dynamically-linked GHCi (and vice versa).

* An unprofiled GHCi can load and run profiled code, which means it
  can use the stack-trace functionality provided by profiling without
  taking the performance hit on the compiler that profiling would
  entail.

Amongst other things; see
https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.

Notes on the implementation are in Note [Remote GHCi] in the new
module compiler/ghci/GHCi.hs.  It probably needs more documenting,
feel free to suggest things I could elaborate on.

Things that are not currently implemented for -fexternal-interpreter:

* The GHCi debugger
* :set prog, :set args in GHCi
* `recover` in Template Haskell
* Redirecting stdin/stdout for the external process

These are all doable, I just wanted to get to a working validate-clean
patch first.

I also haven't done any benchmarking yet.  I expect there to be slight hit
to link times for byte code and some penalty due to having to
serialize/deserialize TH syntax, but I don't expect it to be a serious
problem.  There's also lots of low-hanging fruit in the byte code
generator/linker that we could exploit to speed things up.

Test Plan:
* validate
* I've run parts of the test suite with
EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
There are a few failures due to the things not currently implemented
(see above).

Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite

Subscribers: thomie

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

This exposes `template-haskell` functions for querying the language
extensions which are enabled when compiling a module,

- an `isExtEnabled` function to check whether an extension is enabled
- an `extsEnabled` function to obtain a full list of enabled extensions

To avoid code duplication this adds a `GHC.LanguageExtensions` module to
`ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
consequence of this is that the ungainly `DynFlags` lost around 500
lines. Moreover, flags corresponding to language extensions are now
clearly distinguished from other flags due to the `LangExt.*` prefix.

Updates haddock submodule.

This fixes #10820.

Test Plan: validate

Reviewers: austin, spinda, hvr, goldfire, alanz

Reviewed By: goldfire

Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie

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

GHC Trac Issues: #10820

Summary:
Deriving clauses in the TH representations of data, newtype, data
instance, and newtype instance declarations previously were just [Name],
which didn't allow for more complex derived classes, eg. multi-parameter
typeclasses.

This switches out [Name] for Cxt, representing the derived classes as
types instead of names.

Test Plan: validate

Reviewers: goldfire, spinda, austin

Reviewed By: goldfire, austin

Subscribers: thomie

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

GHC Trac Issues: #10819

Test Plan: validate

Reviewers: bgamari, austin, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #10734

Summary:
Amazingly, there were zero changes to the byte code generator and very
few changes to the interpreter - mainly because we've used good
abstractions that hide the differences between profiling and
non-profiling.  So that bit was pleasantly straightforward, but there
were a pile of other wibbles to get the whole test suite through.

Note that a compiler built with -prof is now like one built with
-dynamic, in that to use TH you have to build the code the same way.
For dynamic, we automatically enable -dynamic-too when TH is required,
but we don't have anything equivalent for profiling, so you have to
explicitly use -prof when building code that uses TH with a profiled
compiler.  For this reason Cabal won't work with TH.  We don't expect
to ship a profiled compiler, so I think that's OK.

Test Plan: validate with GhcProfiled=YES in validate.mk

Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang

Reviewed By: ezyang

Subscribers: thomie

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

GHC Trac Issues: #4837, #545

When TemplateHaskell language extension is enabled it is valid to have
top-level expressions.  Each such expression is treated as a contents
of a splice.  The problem arises with typed splices.  They are not valid
at the top level and therefore we should interpret them not as a splice
but as a top-level expression (aka. implicit splice).  So saying:

$$foo

is equivalent of:

$( $$foo )

This patch makes sure that this is indeed the case.  Until now we
incorrectly treated typed splices as explicit splices.