| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be3d7f661968a7b8c6751c0be3bf23e703b32c3e added Show
instance for Callstack.
That made a couple of error messages to drift as:
instance Show Ordering -- Defined in ‘GHC.Show’
instance Show Integer -- Defined in ‘GHC.Show’
...plus 23 others
- ...plus 20 instances involving out-of-scope types
+ ...plus 21 instances involving out-of-scope types
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
|
| |
|
|
|
|
|
|
|
| |
Previously "types" was inappropriately made plural instead of
"instance",
instance Eq Ordering -- Defined in ‘GHC.Classes’
...plus 24 others
...plus 13 instance involving out-of-scope typess
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan:
```
ghci> import GHC.Stack
ghci> SrcLoc "f" "b" "c" 1 2 3 4
SrcLoc {srcLocPackage = "f", srcLocModule = "b", srcLocFile = "c",
srcLocStartLine = 1, srcLocStartCol = 2, srcLocEndLine = 3,
srcLocEndCol = 4}
```
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: thomie
Projects: #ghc
Differential Revision: https://phabricator.haskell.org/D1886
GHC Trac Issues: #11510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 547c597112954353cef7157cb0a389bc4f6303eb modifies the
pretty-printer to render names from a set of core packages (`base`,
`ghc-prim`, `template-haskell`) as unqualified. The idea here was that
many of these names typically are not in scope but are well-known by the
user and therefore qualification merely introduces noise.
This, however, is a very large hammer and potentially breaks any
consumer who relies on parsing GHC output (hence #11208). This commit
partially reverts this change, now only printing `Constraint` (which
appears quite often in errors) as unqualified.
Fixes #11208.
Updates tests in `array` submodule.
Test Plan: validate
Reviewers: hvr, thomie, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1619
GHC Trac Issues: #11208
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second attempt at merging D757.
This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.
However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.
See particularly
* Note [Grand plan for Typeable] in TcTypeable (which is a new module)
* Note [The overall promotion story] in DataCon (clarifies existing
stuff)
The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:
* We need to have enough data types around to *define* a TyCon
* Many of these types are wired-in
Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.
Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969
* T1969: GHC allocates 19% more
* T4801: GHC allocates 13% more
* T5321FD: GHC allocates 13% more
* T9675: GHC allocates 11% more
* T783: GHC allocates 11% more
* T5642: GHC allocates 10% more
I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.
Remaining to do
~~~~~~~~~~~~~~~
* I think that "TyCon" and "Module" are over-generic names to use for
the runtime type representations used in GHC.Typeable. Better might
be
"TrTyCon" and "TrModule". But I have not yet done this
* Add more info the the "TyCon" e.g. source location where it was
defined
* Use the new "Module" type to help with Trac Trac #10068
* It would be possible to generate TyConRepName (ie Typeable
instances) selectively rather than all the time. We'd need to persist
the information in interface files. Lacking a motivating reason I
have
not done this, but it would not be difficult.
Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular
* In TyCon, a type *family* (whether type or data) is repesented by a
FamilyTyCon
* a algebraic data type (including data/newtype instances) is
represented by AlgTyCon This wasn't true before; a data family
was represented as an AlgTyCon. There are some corresponding
changes in IfaceSyn.
* Also get rid of the (unhelpfully named) tyConParent.
* In TyCon define 'Promoted', isomorphic to Maybe, used when things are
optionally promoted; and use it elsewhere in GHC.
* Cleanup handling of knownKeyNames
* Each TyCon, including promoted TyCons, contains its TyConRepName, if
it has one. This is, in effect, the name of its Typeable instance.
Updates haddock submodule
Test Plan: Let Harbormaster validate
Reviewers: austin, hvr, goldfire
Subscribers: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D1404
GHC Trac Issues: #9858
|
| |
|
|
|
|
|
|
| |
This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c.
This merge was botched
Also reverts haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.
However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.
See particularly
* Note [Grand plan for Typeable] in TcTypeable (which is a new module)
* Note [The overall promotion story] in DataCon (clarifies existing stuff)
The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:
* We need to have enough data types around to *define* a TyCon
* Many of these types are wired-in
Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.
Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969
* T3294: GHC allocates 110% more (filed #11030 to track this)
* T1969: GHC allocates 30% more
* T4801: GHC allocates 14% more
* T5321FD: GHC allocates 13% more
* T783: GHC allocates 12% more
* T9675: GHC allocates 12% more
* T5642: GHC allocates 10% more
* T9961: GHC allocates 6% more
* T9203: Program allocates 54% less
I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.
Remaining to do
~~~~~~~~~~~~~~~
* I think that "TyCon" and "Module" are over-generic names to use for
the runtime type representations used in GHC.Typeable. Better might be
"TrTyCon" and "TrModule". But I have not yet done this
* Add more info the the "TyCon" e.g. source location where it was
defined
* Use the new "Module" type to help with Trac Trac #10068
* It would be possible to generate TyConRepName (ie Typeable
instances) selectively rather than all the time. We'd need to persist
the information in interface files. Lacking a motivating reason I have
not done this, but it would not be difficult.
Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular
* In TyCon, a type *family* (whether type or data) is repesented by a
FamilyTyCon
* a algebraic data type (including data/newtype instances) is
represented by AlgTyCon This wasn't true before; a data family
was represented as an AlgTyCon. There are some corresponding
changes in IfaceSyn.
* Also get rid of the (unhelpfully named) tyConParent.
* In TyCon define 'Promoted', isomorphic to Maybe, used when things are
optionally promoted; and use it elsewhere in GHC.
* Cleanup handling of knownKeyNames
* Each TyCon, including promoted TyCons, contains its TyConRepName, if
it has one. This is, in effect, the name of its Typeable instance.
Requires update of the haddock submodule.
Differential Revision: https://phabricator.haskell.org/D757
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improved error messages are only printed when the old message would be
"No instance for...", since they're not as helpful for "Could not deduce..."
No special test case as error messages are tested by other tests already.
Signed-off-by: David Kraeutmann <kane@kane.cx>
Reviewed By: austin, goldfire
Differential Revision: https://phabricator.haskell.org/D1182
GHC Trac Issues: #10733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For details see #6018, Phab:D202 and the wiki page:
https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies
This patch also wires-in Maybe data type and updates haddock submodule.
Test Plan: ./validate
Reviewers: simonpj, goldfire, austin, bgamari
Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar,
carter
Differential Revision: https://phabricator.haskell.org/D202
GHC Trac Issues: #6018
|
| |
|
|
|
|
|
|
|
|
| |
Summary: See Note [Displaying potential instances].
Reviewers: austin
Subscribers: KaneTW, thomie
Differential Revision: https://phabricator.haskell.org/D1176
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two facilities provide some means to avoid the double-breakage caused by
first by the deprecation (see #2496), and then again by the actual future
field-removal.
See also
https://groups.google.com/d/msg/haskell-core-libraries/q9H-QlL_gnE/4lbb_mBjre8J
for details about this library addition.
Reviewed By: ekmett
Differential Revision: https://phabricator.haskell.org/D577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The intent of this commit is to make test suite cases more stable, so that
it doesn't matter what order we load interface files in, the test output
doesn't change.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D484
|
| |
|
|
| |
I this this arises from my de-orphaning the Enum Word instance
|
| |
|
|
|
|
| |
Also update a few tests, since containers now has IsList instances.
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
|
| |
Now that we're in development mode, Applicative will soon be a
superclass of Monad in HEAD. So let's go ahead and deprecate the
-fno-warn-amp flag, remove the checks, and tweak a few tests
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
| |
This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019)
and therefore looks more familiar on the console. This addresses #2507.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
|
|
| |
The perf tests can probably be rechecked and tightened a little; I fixed
them with AMP the other day but some changes since then have made them
wibble perhaps.
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| | |
|
| |
|
