| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is similar to the AMP patch (#8004), which offered two
functions:
1. Warn when an instance of a class has been given, but the type does
not have a certain superclass instance
2. Warn when top-level definitions conflict with future Prelude names
These warnings are issued as part of the new `-Wcompat` warning group.
Reviewers: hvr, ekmett, austin, bgamari
Reviewed By: hvr, ekmett, bgamari
Subscribers: ekmett, thomie
Differential Revision: https://phabricator.haskell.org/D1539
GHC Trac Issues: #11139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does some signficant refactoring to the treatment
of default methods in class declarations, and more generally
to the type checking of type/class decls.
Highlights:
* When the class has a generic-default method, such as
class C a where
op :: a -> a -> Bool
default op :: Ord a => a -> a -> a
the ClassOpItem records the type of the generic-default,
in this case the type (Ord a => a -> a -> a)
* I killed off Class.DefMeth in favour of the very-similar
BasicTypes.DefMethSpec. However it turned out to be better
to use a Maybe, thus
Maybe (DefMethSpec Type)
with Nothing meaning "no default method".
* In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing],
but I found a way to make it much simpler, accumulating only
a [TyCon]. Much less wrapping and unwrapping.
* On the way I also fixed Trac #10896 in a better way. Instead
of killing off all ambiguity checks whenever there are any type
errors (the fix in commit 8e8b9ed), I instead recover in
TcTyClsDecls.checkValidTyCl.
There was a lot of associated simplification all round
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This puts the "Relevant bindings" section at the end.
It uses a TcErrors.Report Monoid to divide messages by importance and
then mappends them together. This is not the most efficient way since
there are various intermediate Reports and list appends, but it probably
doesn't matter since error messages shouldn't get that large, and are
usually prepended. In practice, everything is `important` except
`relevantBindings`, which is `supplementary`.
ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc,
which has important, context, and suppelementary fields. Each of those
three sections is marked with a bullet character, '•' on unicode
terminals and '*' on ascii terminals. Since this breaks tons of tests,
I also modified testlib.normalise_errmsg to strip out '•'s.
--- Additional notes:
To avoid prepending * to an empty doc, I needed to filter empty docs.
This seemed less error-prone than trying to modify everyone who produces
SDoc to instead produce Maybe SDoc. So I added `Outputable.isEmpty`.
Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise
I think I'd need another Empty case for SDoc, and then it couldn't be a
newtype any more.
ErrMsg's errMsgShortString is only used by the Show instance, which is
in turn only used by Show HscTypes.SourceError, which is in turn only
needed for the Exception instance. So it's probably possible to get rid
of errMsgShortString, but that would a be an unrelated cleanup.
Fixes #11014.
Test Plan: see above
Reviewers: austin, simonpj, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: simonpj, nomeata, thomie
Differential Revision: https://phabricator.haskell.org/D1427
GHC Trac Issues: #11014
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed to allow subsequent patches to refer to `*>`.
While at it, this commit also groups together the `Applicative` definitions
to reduce confusion.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1513
|
|
|
|
|
|
| |
This responds to Trac #11112 by improving the error message
when the kind checker discovers something of kind Constraint
used when a type is expected
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After the changes, the three functions used to print type families
were identical, so they are refactored into one.
Original RHSs of data instance declarations are recreated and
printed in user error messages.
RHSs containing representation TyCons are printed in the
Coercion Axioms section in a typechecker dump.
Add vbar to the list of SDocs exported by Outputable.
Replace all text "|" docs with it.
Fixes #10839
Reviewers: goldfire, jstolarek, austin, bgamari
Reviewed By: jstolarek
Subscribers: jstolarek, thomie
Differential Revision: https://phabricator.haskell.org/D1441
GHC Trac Issues: #10839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit 06d46b1e4507e09eb2a7a04998a92610c8dc6277.
This also has a Haddock submodule update.
Test Plan: validate
Reviewers: simonpj, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements Lennart's idea from the Haskell Symposium.
Users may use the special type function `TypeError`, which is
similar to `error` at the value level.
See Trac ticket https://ghc.haskell.org/trac/ghc/ticket/9637, and wiki
page https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros
Test Plan: Included testcases
Reviewers: simonpj, austin, hvr, goldfire, bgamari
Reviewed By: goldfire, bgamari
Subscribers: adamgundry, thomie
Differential Revision: https://phabricator.haskell.org/D1236
GHC Trac Issues: #9637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new language extension `-XStrict` which turns all bindings strict
as if the programmer had written a `!` before it. This also upgrades
ordinary Haskell to allow recursive and polymorphic strict bindings.
See the wiki[1] and the Note [Desugar Strict binds] in DsBinds for
specification and implementation details.
[1] https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
Reviewers: austin, tibbe, simonpj, bgamari
Reviewed By: tibbe, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1142
GHC Trac Issues: #8347
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The idea here is that this gives a more detailed stack trace in two
cases:
1. With `-prof` and `-fprof-auto`
2. In GHCi (see #11047)
Example, with an error inserted in nofib/shootout/binary-trees:
```
$ ./Main 3
Main: z
CallStack (from ImplicitParams):
error, called at Main.hs:67:29 in main:Main
CallStack (from -prof):
Main.check' (Main.hs:(67,1)-(68,82))
Main.check (Main.hs:63:1-21)
Main.stretch (Main.hs:32:35-57)
Main.main.c (Main.hs:32:9-57)
Main.main (Main.hs:(27,1)-(43,42))
Main.CAF (<entire-module>)
```
This doesn't quite obsolete +RTS -xc, which also attempts to display
more information in the case when the error is in a CAF, but I'm
exploring other solutions to that.
Includes submodule updates.
Test Plan: validate
Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For abstract type families we incorrectly rejected their injectivity
annotation. Fixes #11007.
Test Plan: #6018
Reviewers: goldfire, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1453
GHC Trac Issues: #11007
|
|
|
|
|
|
|
|
|
|
|
| |
This also needs to update the primitive/vector submodules in order to
relax upper bounds on ghc-prim.
Like in f8ba4b55cc3a061458f5cfabf17de96128defbbb, a mass-rewrite in testsuite/ via
sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc-prim-0.4.0.0')
was performed.
|
|
|
|
|
|
|
|
|
|
|
| |
This also relaxes a few upper bounds on base in the ghc.git repo;
This required a mass-rewrite in testsuite/
sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')
because it turns out the testsuite is still sensitive to package version
changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fixes Trac #10997
Merge to stable branch
|
| |
|
|
|
|
|
|
|
|
| |
Default rules deliberately accept any kind.
Reviewed By: simonpj, thomie, goldfire
Differential Revision: https://phabricator.haskell.org/D1329
|
|
|
|
|
|
|
|
| |
This fallout was caused by f8fbf385b879fe17740 (see #10935), and looks easy
enough, but admittedly I just tried patching the output, so we're doing it
live.
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is driven by Trac #10935, and reinstates the
-fwarn-monomorphism-restriction warning. It was first lost in 2010:
d2ce0f52d "Super-monster patch implementing the new typechecker -- at
last"
I think the existing documentation is accurate; it is not even
turned on by -Wall.
I added one test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of doing these warnings at MkIface time, we do them
when we create the instances/rules in the typechecker/desugarer.
Emitting warnings for auto-generated instances was a pain
(since the specialization monad doesn't have the capacity
to emit warnings) so instead I just deprecated -fwarn-auto-orphans.
Auto rule orphans are pretty harmless anyway: they don't cause
interface files to be eagerly loaded in.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch drops the file level distinction between hs-boot and hsig;
we figure out which one we are compiling based on whether or not there
is a corresponding hs file lying around.
To make the "import A" syntax continue to work for bare hs-boot
files, we also introduce hs-boot merging, which takes an A.hi-boot
and converts it to an A.hi when there is no A.hs file in scope.
This will be generalized in Backpack to merge multiple A.hi files together;
which means we can jettison the "load multiple interface files" functionality.
This works automatically for --make, but for one-shot compilation
we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
from a local A.hi-boot file; Backpack will extend this mechanism further.
Has Haddock submodule update to deal with change in msHsFilePath behavior.
- This commit drops support for the hsig extension. Can
we support it? It's annoying because the finder code is
written with the assumption that where there's an hs-boot
file, there's always an hs file too. To support hsig, you'd
have to probe two locations. Easier to just not support it.
- #10333 affects us, modifying an hs-boot still doesn't trigger
recomp.
- See compiler/main/Finder.hs: this diff is very skeevy, but
it seems to work.
- This code cunningly doesn't drop hs-boot files from the
"drop hs-boot files" module graph, if they don't have a
corresponding hs file. I have no idea if this actually is useful.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari, spinda
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1098
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes #10896. In the indexed-types/should_fail/BadSock test,
there is a bad type definition. This gets type-checked, an error
gets reported, but then **GHC keeps going**. Later, when
running the simplifier to do an ambiguity check, the bad type
environment causes GHC to fall over. My solution: only run the
simplifier in a clean, error-free type environment.
A downside of this is that fewer error messages are reported.
This makes me a bit sad, but I'm not sure how to avoid the problem.
Suggestions welcome.
|
|
|
|
|
|
|
|
|
| |
This fixes #10817 and #10899. A knock-on effect is that we must
now remember locations of associated type defaults for error
messages during validity checking. This isn't too bad, but it
increases the size of the diff somewhat.
Test cases: indexed-types/should_fail/T108{17,99}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes two real changes:
- Equalities like (a ~R [a]) really *are* insoluble. Previously,
GHC refused to give up when an occurs check bit on a representational
equality. But for datatypes, it really should bail.
- Now, GHC will sometimes report an occurs check error (in cases above)
for representational equalities. Previously, it never did.
This "fixes" #10715, where by "fix", I mean clarifies the error message.
It's unclear how to do more to fix that ticket.
Test cases: typecheck/should_fail/T10715{,b}
|
|
|
|
| |
Thanks to Gabor Greif for spotting the mistake.
|
|
|
|
| |
The previous message was wrong, as pointed out by Jan Stolarek.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tcFamTyPats now must take information about the instantiation of any
class variables, when checking the instance of an associated type.
Getting this to work out required some unexpected refactoring in
TcDeriv. TcDeriv needs to look at class instances because of the
possibility of associated datatypes with `deriving` specs. TcDeriv
worked over the user-specified instances. But any data family instances
were already processed, and TcDeriv had no way of finding the rep
tycons. Indeed, TcDeriv *re-type-checked* any data family instances
in an attempt to rediscover what GHC already knew. So, this commit
introduces better tracking of compiled data families between TcInstDcls
and TcDeriv to streamline all of this.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1250
|
|
|
|
|
|
|
|
|
|
|
| |
Show the minimal complete definition on :info in ghci. They
are shown like MINIMAL pragmas in code. If the minimal complete
definition is empty or only a specific method from a class is
requested, nothing is shown.
Reviewed By: simonpj, austin, thomie
Differential Revision: https://phabricator.haskell.org/D1241
|
|
|
|
|
| |
As a result of fixing #10836 it is now possible to merge 11 different
tests for #6018 into one
|
|
|
|
|
|
|
|
| |
I think this patch finally works around the delicacy in the strictness
of TcTyClsDecls.rejigConRes. See the notes with that function and
Note [Checking GADT return types].
As a result, we fix Trac #10836, and improve Trac #7175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes validate.
374457809de343f409fbeea0a885877947a133a2 (D202) mentions: "This patch
also wires-in Maybe data type".
A conflicting definition of a wired-in type in a .hsig file doesn't seem
to cause compilation to fail. This is probably a bug, but a small one.
Since SPJ in ffc21506894c7887d3620423aaf86bc6113a1071 swept this under
the rug, by removing `data Bool a b c d = False` from tcfail220.hsig,
I'm going to do the same here.
D1098 touches these files, so ezyang can decide whether this problem
warrants fixing when doing a rebase.
Differential Revision: https://phabricator.haskell.org/D1208
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`make test` now runs all tests for a single way only. Use `make slowtest` to
get the previous behaviour (i.e. run all tests for all ways).
The intention is to use this new `make test` setting for Phabricator, as
a reasonable compromise between `make fasttest` (what it previously
used) and a fullblown `make slowtest` (which runs all tests for all
ways).
See Note [validate and testsuite speed] in toplevel Makefile.
Differential Revision: https://phabricator.haskell.org/D1178
|
|
|
|
|
|
|
|
|
|
| |
I didn't realize that `./validate` does not run every test :(
Test Plan: ./validate --slow
Update submodule hpc.
Differential Revision: https://phabricator.haskell.org/D1204
|
|
|
|
|
|
|
|
|
|
| |
Summary: See Note [Displaying potential instances].
Reviewers: austin
Subscribers: KaneTW, thomie
Differential Revision: https://phabricator.haskell.org/D1176
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1193
|
|
|
|
| |
No major deviations. Also fixup T7861.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backport of a bug fix by Benedikt Huber for the same problem
in the pretty library (#1337), from commit
8d8866a8379c2fe8108ef034893c59e06d5e752f. The original explanation for
the fix is attached below.
Ticket #1776 originally reported an infinite loop when printing error
message. This promptly got fixed in:
commit 2d52ee06786e5caf0c2d65a4b4bb7c45c6493190
Author: simonpj@microsoft.com <unknown>
Date: Thu Mar 1 11:45:13 2007 +0000
Do not go into an infinite loop when pretty-printer finds a
negative indent (Trac #1176)
SPJ reports in the ticket: "So infinite loop is fixed, but the bad
formatting remains. I've added a test, tcfail177."
tcfail177 however hasn't triggered the formatting problem for years (as
Ian reported in c9e0e6067a47c574d9ff3721afe58e30ca1be3e4).
This patch updates the test to a version that at least still failed with
ghc-7.0 (from #1776#comment:7).
-------------------
From https://mail.haskell.org/pipermail/libraries/2008-June/010013.html,
by Benedikt Huber:
Concerning ticket #1337, we have to change the formal specification of
fill (it doesn't match the implementation):
-- Current Specification:
-- fill [] = empty
-- fill [p] = p
-- fill (p1:p2:ps) = oneLiner p1 <#> nest (length p1)
-- (fill (oneLiner p2 : ps))
-- `union`
-- p1 $$ fill ps
Problem 1: We want to `unnest' the second argument of (p1 $$ fill ps),
but not the first one
In the definition above we have e.g.
> getSecondLayout $
> fillDef False [text "a", text "b", text "a"]
>> text "ab"; nilabove; nest -1; text "a"; empty
>> |ab|
>> |.a|
Problem 2: The overlapping $$ should only be used for those layouts of
p1 which aren't one liners (otherwise violating the invariant "Left
union arg has shorter first line").
I suggest the following specification (i believe it almost matches the
current implementation, modulo [fillNB: fix bug #1337] (see below):
-- Revised Specification:
-- fill g docs = fill' 0 docs
-- gap g = if g then 1 else 0
-- fill' n [] = []
-- fill' n [p] = [p]
-- fill' n (p1:p2:ps) =
-- oneLiner p1 <g> (fill' (n+length p1+gap g) (oneLiner p2 : ps))
-- `union`
-- (p1 $*$ nest (-n) (fill' g ps))
--
-- $*$ is defined for layouts (One-Layout Documents) as
--
-- layout1 $*$ layout2 | isOneLiner layout1 = layout1 $+$ layout2
-- | otherwise = layout1 $$ layout2
I've also implemented the specification in HughesPJQuickCheck.hs,
and checked them against the patched pretty printer.
Concerning Bug #1337:
~~~~~~~~~~~~~~~~~~~~~
If the above formal specification is fine, it is easy to fix:
elide the nests of (oneLiner p2) [see attached patch, record bug #1337].
> PrettyPrint(0) $ ./Bug1337
> ....ab
> ...c
The (long) explanation follows below.
<snip/>
===========================================================
Explanation of Bug #1337:
Consider
> fcat [ nest 1 $ text "a", nest 2 $ text "b", text "c"]
--> expected: (nest 1; text "a"; text "b"; nest -3; "c")
--> actual : (nest 1; text "a"; text "b"; nest -5; "c")
Reduction:
=== (nest 1; text a) <> (fill (-2) (p2:ps))
==> (nest 2 (text "b") $+$ text "c")
==> (nest 2 (text "b")) `nilabove`
(nest (-3) (text "c"))
==> (nest 1; text a; text b; nest -5 c)
The problem is that if we decide to layout (p1:p2:ps) as
| p1 p2
| ps
(call it layout A), then we want to have
> (p1 <> p2) $+$ ps.
But following law <n6> this means that
> fcat_A [p1:nest k p2:ps]
is equivalent to
> fcat_A [p1,p2,ps]
so the nest of p2 has to be removed.
This is somewhat similar to bug #667, but easier to fix
from a semantic point of view:
p1,p2 and ps are distinct layouts - we only have to preserve the
individual layouts, and no combinations of them.
|
|
|
|
|
|
|
|
|
| |
akio wants to use oneShot with unlifted types as well, and there is no
good reason not to let him. This changes the type of the built-in
oneShot definition to open kinds, and also expand the documentation a
little bit.
Differential Revision: https://phabricator.haskell.org/D1136
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When examining #10615, I found the wildcard handling hard
to understand. This patch refactors quite a bit, but with
no real change in behaviour.
* Split out TcIdSigInfo from TcSigInfo, as a separate type,
like TcPatSynInfo.
* Make TcIdSigInfo express more invariants by pushing the
wildard info into TcIdSigBndr
* Remove all special treatment of unification variables that arise
from wildcards; so the TauTv of TcType.MetaInfo loses its Bool
argument.
A ton of konck on changes. The result is significantly simpler, I think.
|
| |
|