| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This re-working of the typechecker algorithm is based on
the paper "Visible type application", by Richard Eisenberg,
Stephanie Weirich, and Hamidhasan Ahmed, to be published at
ESOP'16.
This patch introduces -XTypeApplications, which allows users
to say, for example `id @Int`, which has type `Int -> Int`. See
the changes to the user manual for details.
This patch addresses tickets #10619, #5296, #10589.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch began as a modest refactoring of HsType and friends, to
clarify and tidy up exactly where quantification takes place in types.
Although initially driven by making the implementation of wildcards more
tidy (and fixing a number of bugs), I gradually got drawn into a pretty
big process, which I've been doing on and off for quite a long time.
There is one compiler performance regression as a result of all
this, in perf/compiler/T3064. I still need to look into that.
* The principal driving change is described in Note [HsType binders]
in HsType. Well worth reading!
* Those data type changes drive almost everything else. In particular
we now statically know where
(a) implicit quantification only (LHsSigType),
e.g. in instance declaratios and SPECIALISE signatures
(b) implicit quantification and wildcards (LHsSigWcType)
can appear, e.g. in function type signatures
* As part of this change, HsForAllTy is (a) simplified (no wildcards)
and (b) split into HsForAllTy and HsQualTy. The two contructors
appear when and only when the correponding user-level construct
appears. Again see Note [HsType binders].
HsExplicitFlag disappears altogether.
* Other simplifications
- ExprWithTySig no longer needs an ExprWithTySigOut variant
- TypeSig no longer needs a PostRn name [name] field
for wildcards
- PatSynSig records a LHsSigType rather than the decomposed
pieces
- The mysterious 'GenericSig' is now 'ClassOpSig'
* Renamed LHsTyVarBndrs to LHsQTyVars
* There are some uninteresting knock-on changes in Haddock,
because of the HsSyn changes
I also did a bunch of loosely-related changes:
* We already had type synonyms CoercionN/CoercionR for nominal and
representational coercions. I've added similar treatment for
TcCoercionN/TcCoercionR
mkWpCastN/mkWpCastN
All just type synonyms but jolly useful.
* I record-ised ForeignImport and ForeignExport
* I improved the (poor) fix to Trac #10896, by making
TcTyClsDecls.checkValidTyCl recover from errors, but adding a
harmless, abstract TyCon to the envt if so.
* I did some significant refactoring in RnEnv.lookupSubBndrOcc,
for reasons that I have (embarrassingly) now totally forgotten.
It had to do with something to do with import and export
Updates haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In spirit, this reverts 9ba922ee06b048774d7a82964867ff768a78126e
The syntax has been deprecated with a warning since 2010.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1530
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since f16ddcee0c64a92ab911a7841a8cf64e3ac671fd / D876, `ghc-stage1`
supports a subset of `-XTemplateHaskell`, but since we need Cabal to be
able detect (so `.cabal` files can be specified accordingly, see also
GHC #11102 which omits `TemplateHaskell` from `--supported-extensions`)
whether GHC provides full or only partial `-XTemplateHaskell` support,
the proper way to accomplish this is to split off the
quotation/non-splicing `TemplateHaskell` feature-subset into a new
language pragma `TemplateHaskellQuotes`.
Moreover, `-XTemplateHaskellQuotes` is considered safe under SafeHaskell
This addresses #11121
Reviewers: goldfire, ezyang, dterei, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1511
GHC Trac Issues: #11121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment the API Annotations can only be used on the ParsedSource,
as there are changes made to the RenamedSource that prevent it from
being used to round trip source code.
It is possible to build a map from every Located Name in the
RenamedSource from its location to the Name, which can then be used when
resolved names are required when changing the ParsedSource.
However, there are instances where the identifier is not located,
specifically
(GHC.VarPat name)
(GHC.HsVar name)
(GHC.UserTyVar name)
(GHC.HsTyVar name)
Replace each of the name types above with (Located name)
Updates the haddock submodule.
Test Plan: ./validate
Reviewers: austin, goldfire, bgamari
Reviewed By: bgamari
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1512
GHC Trac Issues: #11019
|
| |
|
|
|
| |
Fixes #10267. Typed holes in typed Template Haskell currently don't work.
See #10945 and #10946.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a simple refactoring that prepares for a later one,
related to Trac #10083.
* Add a field tcg_self_boot :: SelfBootInfo to TcGblEnv,
where SelfBootInfo is a new data type, describing the
hi-boot file, if any, for the module being compiled.
* Make tcHiBootIface return SelfBootInfo, a new data type
* Make other functions get SelfBootInfo from the monad.
* Remove tcg_mod_name from TcGblEnv; it was barely used and
simpler to pass around explicitly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Declaration splices: partial type signatures are fully supported in TH
declaration splices.
For example, the wild cards in the example below will unify with `Eq
a`
and `a -> a -> Bool`, as expected:
```
[d| foo :: _ => _
foo x y = x == y |]
```
- Expression splices: anonymous and named wild cards are supported in
expression signatures, but extra-constraints wild cards aren't. Just
as is the case for regular expression signatures.
```
[e | Just True :: _a _ |]
```
- Typed expression splices: the same wildcards as in (untyped)
expression splices are supported.
- Pattern splices: TH doesn't support type signatures in pattern
splices, consequently, partial type signatures aren't supported
either.
- Type splices: partial type signatures are only partially supported in
type splices, specifically: only anonymous wild cards are allowed.
So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or
`[| _a |]` won't (without `-XNamedWildCards`, the latter will work as
the named wild card is treated as a type variable).
Normally, named wild cards are collected before renaming a (partial)
type signature. However, TH type splices are run during renaming, i.e.
after the initial traversal, leading to out of scope errors for named
wild cards. We can't just extend the initial traversal to collect the
named wild cards in TH type splices, as we'd need to expand them,
which is supposed to happen only once, during renaming.
Similarly, the extra-constraints wild card is handled right before
renaming too, and is therefore also not supported in a TH type splice.
Another reason not to support extra-constraints wild cards in TH type
splices is that a single signature can contain many TH type splices,
whereas it mustn't contain more than one extra-constraints wild card.
Enforcing would this be hard the way things are currently organised.
Anonymous wild cards pose no problem, because they start without names
and are given names during renaming. These names are collected right
after renaming. The names generated for anonymous wild cards in TH
type splices will thus be collected as well.
With a more invasive refactoring of the renaming, partial type
signatures could be fully supported in TH type splices. As only
anonymous wild cards have been requested so far, these small changes
satisfying this request will do for now. Also don't forget that a TH
declaration splices support all kinds of wild cards.
- Extra-constraints wild cards were silently ignored in expression and
pattern signatures, appropriate error messages are now generated.
Test Plan: run new tests
Reviewers: austin, goldfire, adamgundry, bgamari
Reviewed By: goldfire, adamgundry, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1048
GHC Trac Issues: #10094, #10548
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The load was introduced a32d3e4da0aceb624c958f02cad7327e17ac94db
to fix a bug where deprecations assumed that the name in question
had already had their interface loaded. The new deprecation
code no longer makes this assumption and just loads the interface,
so this eager load is not necessary.
Verified that TH_reifyType2 continues to work.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D891
GHC Trac Issues: #10419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
- Haddock needs to absorb the change too; so there is a submodule update
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts multiple commits from Simon:
- 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359
- a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403
- c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248
- eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first
- ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon
- 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule
- 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet
- a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2)
- a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build
- 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg
- 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints
- 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line
These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit adds stage 1 support for Template Haskell
quoting, e.g. [| ... expr ... |], which is useful
for authors of quasiquoter libraries that do not actually
need splices. The TemplateHaskell extension now does not
unconditionally fail; it only fails if the renamer encounters
a splice that it can't run.
In order to make sure the referenced data structures
are consistent, template-haskell is now a boot library.
There are some minor BC changes to template-haskell to make it boot
on GHC 7.8.
Note for reviewer: big diff changes are simply code
being moved out of an ifdef; there was no other substantive
change to that code.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, goldfire
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D876
GHC Trac Issues: #10382
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "Quick fix: drop base bound on template-haskell."
This reverts commit 3c70ae032e4361b203dfcf22b0a424e8838a5037.
Revert "Always do polymorphic typed quote check, c.f. #10384"
This reverts commit 9a43b2c1f78b3cf684646af64b9b67dc8079f58f.
Revert "RnSplice's staging test should be applied for quotes in stage1."
This reverts commit eb0ed4030374af542c0a459480d32c8d4525e48d.
Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler."
This reverts commit 21c72e7d38c96ac80d31addf67ae4b3c7a6c3bbb.
Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382."
This reverts commit 28257cae77023f2ccc4cc1c0cd1fbbd329947a00.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D878
GHC Trac Issues: #10382
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit adds stage 1 support for Template Haskell
quoting, e.g. [| ... expr ... |], which is useful
for authors of quasiquoter libraries that do not actually
need splices. The TemplateHaskell extension now does not
unconditionally fail; it only fails if the renamer encounters
a splice that it can't run.
In order to make sure the referenced data structures
are consistent, template-haskell is now a boot library.
In the following patches, there are:
- A few extra safety checks which should be enabled
in stage1
- Separation of the th/ testsuite into quotes/ which
can be run on stage1
Note for reviewer: big diff changes are simply code
being moved out of an ifdef; there was no other substantive
change to that code.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, goldfire
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D876
GHC Trac Issues: #10382
|
| |
|
|
|
| |
...to make clearer what the cross-stage lifting code
applies to (c.f. Trac #10384)
|
| |
|
|
|
|
|
| |
Clarify that repeated checkCrossStageLifting in RnSplice/TcExpr
check untyped/typed brackets, respectively.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
| |
|
|
|
|
| |
See Note [Extra dependencies from .hs-boot files] in RnSource
No change in behaviour
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed
to behave exactly like $(n "...blah..."). But it doesn't! This was outright
wrong: quasiquotes were being run even inside brackets.
Now that TH supports both typed and untyped splices, a quasi-quote is properly
regarded as a particular syntax for an untyped splice. But apart from that
they should be treated the same. So this patch refactors the handling of
quasiquotes to do just that.
The changes touch quite a lot of files, but mostly in a routine way.
The biggest changes by far are in RnSplice, and more minor changes in
TcSplice. These are the places where there was real work to be done.
Everything else is routine knock-on changes.
* No more QuasiQuote forms in declarations, expressions, types, etc.
So we get rid of these data constructors
* HsBinds.QuasiQuoteD
* HsExpr.HsSpliceE
* HsPat.QuasiQuotePat
* HsType.HsQuasiQuoteTy
* We get rid of the HsQuasiQuote type altogether
* Instead, we augment the HsExpr.HsSplice type to have three
consructors, for the three types of splice:
* HsTypedSplice
* HsUntypedSplice
* HsQuasiQuote
There are some related changes in the data types in HsExpr near HsSplice.
Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour.
* In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one.
A smaller, clearer interface.
* We have to update the Haddock submodule, to accommodate the hsSyn changes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that.
Reviewers: austin, jstolarek, hvr, goldfire
Reviewed By: austin, jstolarek
Subscribers: thomie, goldfire
Differential Revision: https://phabricator.haskell.org/D621
GHC Trac Issues: #9986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
see Trac #8624
similar functionality is now available
with -ddump-to-file -ddump-splices
However, users are already accustomed to -ddump-splices
having a particular format, and this format is not completely valid code
The goal of -th-file is to dump valid Haskell code
Additionally, the convention of -ddump-to-file is to name the file after
the flag, so the file is .dump-splices
Given that the goal of the new flag is to generate valid Haskell,
The extension should be .hs
Additionally, -ddump-to-file effects all other dump flags
Test Plan:
look at the output of using the -th-file flag
and compare it to the output of using -ddump-to-file and -ddump-splices
I want to add test cases, but just need some pointers on getting started there
Reviewers: thomie, goldfire, simonpj, austin
Reviewed By: simonpj, austin
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D518
GHC Trac Issues: #8624
|
|
|
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
