| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Silent superclass parameters solve the problem that
the superclasses of a dicionary construction can easily
turn out to be (wrongly) bottom. The problem and solution
are described in
Note [Silent superclass arguments] in TcInstDcls
I first implemented this fix (with Dimitrios) in Dec 2010, but removed
it again in Jun 2011 becuase we thought it wasn't necessary any
more. (The reason we thought it wasn't necessary is that we'd stopped
generating derived superclass constraints for *wanteds*. But we were
wrong; that didn't solve the superclass-loop problem.)
So we have to re-implement it. It's not hard. Main features:
* The IdDetails for a DFunId says how many silent arguments it has
* A DFunUnfolding describes which dictionary args are
just parameters (DFunLamArg) and which are a function to apply
to the parameters (DFunPolyArg). This adds the DFunArg type
to CoreSyn
* Consequential changes to IfaceSyn. (Binary hi file format changes
slightly.)
* TcInstDcls changes to generate the right dfuns
* CoreSubst.exprIsConApp_maybe handles the new DFunUnfolding
The thing taht is *not* done yet is to alter the vectoriser to
pass the relevant extra argument when building a PA dictionary.
|
|
|
|
| |
It isn't really an option at all
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch re-implements implicit parameters via a class
with a functional dependency:
class IP (n::Symbol) a | n -> a where
ip :: a
This definition is in the library module GHC.IP. Notice
how it use a type-literal, so we can have constraints like
IP "x" Int
Now all the functional dependency machinery works right to make
implicit parameters behave as they should.
Much special-case processing for implicit parameters can be removed
entirely. One particularly nice thing is not having a dedicated
"original-name cache" for implicit parameters (the nsNames field of
NameCache). But many other cases disappear:
* BasicTypes.IPName
* IPTyCon constructor in Tycon.TyCon
* CIPCan constructor in TcRnTypes.Ct
* IPPred constructor in Types.PredTree
Implicit parameters remain special in a few ways:
* Special syntax. Eg the constraint (IP "x" Int) is parsed
and printed as (?x::Int). And we still have local bindings
for implicit parameters, and occurrences thereof.
* A implicit-parameter binding (let ?x = True in e) amounts
to a local instance declaration, which we have not had before.
It just generates an implication contraint (easy), but when
going under it we must purge any existing bindings for
?x in the inert set. See Note [Shadowing of Implicit Parameters]
in TcSimplify
* TcMType.sizePred classifies implicit parameter constraints as size-0,
as before the change
There are accompanying patches to libraries 'base' and 'haddock'
All the work was done by Iavor Diatchki
|
|
|
|
|
|
|
| |
A side-effect is that we can no longer use the LogAction in
defaultErrorHandler, as we don't have DynFlags at that point.
But all that defaultErrorHandler did is to print Strings as
SevFatal, so now it takes a 'FatalMessager' instead.
|
|
|
|
|
| |
By using Haskell's debugIsOn rather than CPP's "#ifdef DEBUG", we
don't need to kludge things to keep the warning checker happy etc.
|
|
|
|
| |
It was printing directly to stdout
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows, for the first time, case expressions with an empty
list of alternatives. Max suggested the idea, and Trac #6067 showed
that it is really quite important.
So I've implemented the idea, fixing #6067. Main changes
* See Note [Empty case alternatives] in CoreSyn
* Various foldr1's become foldrs
* IfaceCase does not record the type of the alternatives.
I added IfaceECase for empty-alternative cases.
* Core Lint does not complain about empty cases
* MkCore.castBottomExpr constructs an empty-alternative case
expression (case e of ty {})
* CoreToStg converts '(case e of {})' to just 'e'
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
compiler/coreSyn/CoreLint.lhs
compiler/deSugar/DsBinds.lhs
compiler/hsSyn/HsTypes.lhs
compiler/iface/IfaceType.lhs
compiler/rename/RnHsSyn.lhs
compiler/rename/RnTypes.lhs
compiler/stgSyn/StgLint.lhs
compiler/typecheck/TcHsType.lhs
compiler/utils/ListSetOps.lhs
|
| |
| |
| |
| |
| |
| | |
Jose's patch implementing kind-polymorphic core (09015be8d580bc33f5f1960c8e31d00ba7a459a1) reverted many of the simplifying changes to interface file TyCon serialization I had made in a previous patch (5d7173f9ab8405511f75765e0541a04796d9bd07). Based on the diff I think this was an unintended consequence of how Jose did the merge rather than a real change he intended to make.
In fact, as a result of kind-polymorphic core we don't need to treat the Any TyCon specially any longer so my old simplifying changes can be made even simpler: IfaceTyCon is now just a newtype on IfaceExtName.
|
| |
| |
| |
| |
| |
| | |
It's not clear whether it's desirable or not, and it turns out that
the way we use coercions in GHC means we tend to lose information
about type synonyms.
|
| |
| |
| |
| |
| |
| |
| | |
For now, the syntax is
type {-# CTYPE "some C type" #-} Foo = ...
newtype {-# CTYPE "some C type" #-} Foo = ...
data {-# CTYPE "some C type" #-} Foo = ...
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These are types that look like "this" and "that".
They are of kind `Symbol`, defined in module `GHC.TypeLits`.
For each type-level symbol `X`, we have a singleton type, `TSymbol X`.
The value of the singleton type can be named with the overloaded
constant `tSymbol`. Here is an example:
tSymbol :: TSymbol "Hello"
|
|\ \
| |/
| |
| |
| | |
Conflicts:
compiler/typecheck/TcEvidence.lhs
|
| | |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch should have no user-visible effect. It implements a
significant internal refactoring of the way that FC axioms are
handled. The ultimate goal is to put us in a position to implement
"pattern-matching axioms". But the changes here are only does
refactoring; there is no change in functionality.
Specifically:
* We now treat data/type family instance declarations very,
very similarly to types class instance declarations:
- Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with
FamInstEnv.FamInst. This change does affect the GHC API, but
for the better I think.
- Previously, each family type/data instance declaration gave rise
to a *TyCon*; typechecking a type/data instance decl produced
that TyCon. Now, each type/data instance gives rise to
a *FamInst*, by direct analogy with each class instance
declaration giving rise to a ClsInst.
- Just as each ClsInst contains its evidence, a DFunId, so each FamInst
contains its evidence, a CoAxiom. See Note [FamInsts and CoAxioms]
in FamInstEnv. The CoAxiom is a System-FC thing, and can relate any
two types, whereas the FamInst relates directly to the Haskell source
language construct, and always has a function (F tys) on the LHS.
- Just as a DFunId has its own declaration in an interface file, so now
do CoAxioms (see IfaceSyn.IfaceAxiom).
These changes give rise to almost all the refactoring.
* We used to have a hack whereby a type family instance produced a dummy
type synonym, thus
type instance F Int = Bool -> Bool
translated to
axiom FInt :: F Int ~ R:FInt
type R:FInt = Bool -> Bool
This was always a hack, and now it's gone. Instead the type instance
declaration produces a FamInst, whose axiom has kind
axiom FInt :: F Int ~ Bool -> Bool
just as you'd expect.
* Newtypes are done just as before; they generate a CoAxiom. These
CoAxioms are "implicit" (do not generate an IfaceAxiom declaration),
unlike the ones coming from family instance declarations. See
Note [Implicit axioms] in TyCon
On the whole the code gets significantly nicer. There were consequential
tidy-ups in the vectoriser, but I think I got them right.
|
|/
|
|
|
| |
Currently, we support only numeric literals but---hopefully---these
modifications should make it fairly easy to add other ones, if necessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Attach a SrcSpan to every CostCentre. This had the side effect
that CostCentres that used to be merged because they had the same
name are now considered distinct; so I had to add a Unique to
CostCentre to give them distinct object-code symbols.
- New flag: -fprof-auto-calls. This flag adds an automatic SCC to
every call site (application, to be precise). This is typically
more useful for call stacks than annotating whole functions.
Various tidy-ups at the same time: removed unused NoCostCentre
constructor, and refactored a bit in Coverage.lhs.
The call stack we get from traceStack now looks like this:
Stack trace:
Main.CAF (<entire-module>)
Main.main.xs (callstack002.hs:18:12-24)
Main.map (callstack002.hs:13:12-16)
Main.map.go (callstack002.hs:15:21-34)
Main.map.go (callstack002.hs:15:21-23)
Main.f (callstack002.hs:10:7-43)
|
|
|
|
|
|
|
|
|
| |
This big patch implements a kind-polymorphic core for GHC. The current
implementation focuses on making sure that all kind-monomorphic programs still
work in the new core; it is not yet guaranteed that kind-polymorphic programs
(using the new -XPolyKinds flag) will work.
For more information, see http://haskell.org/haskellwiki/GHC/Kinds
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Let GHC know about an external dependency that Template Haskell uses
so that GHC can recompile when the dependency changes.
No support for ghc -M
There is a corresponding addition to the template-haskell library
|
|
|
|
|
| |
We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
User visible changes
====================
Profilng
--------
Flags renamed (the old ones are still accepted for now):
OLD NEW
--------- ------------
-auto-all -fprof-auto
-auto -fprof-exported
-caf-all -fprof-cafs
New flags:
-fprof-auto Annotates all bindings (not just top-level
ones) with SCCs
-fprof-top Annotates just top-level bindings with SCCs
-fprof-exported Annotates just exported bindings with SCCs
-fprof-no-count-entries Do not maintain entry counts when profiling
(can make profiled code go faster; useful with
heap profiling where entry counts are not used)
Cost-centre stacks have a new semantics, which should in most cases
result in more useful and intuitive profiles. If you find this not to
be the case, please let me know. This is the area where I have been
experimenting most, and the current solution is probably not the
final version, however it does address all the outstanding bugs and
seems to be better than GHC 7.2.
Stack traces
------------
+RTS -xc now gives more information. If the exception originates from
a CAF (as is common, because GHC tends to lift exceptions out to the
top-level), then the RTS walks up the stack and reports the stack in
the enclosing update frame(s).
Result: +RTS -xc is much more useful now - but you still have to
compile for profiling to get it. I've played around a little with
adding 'head []' to GHC itself, and +RTS -xc does pinpoint the problem
quite accurately.
I plan to add more facilities for stack tracing (e.g. in GHCi) in the
future.
Coverage (HPC)
--------------
* derived instances are now coloured yellow if they weren't used
* likewise record field names
* entry counts are more accurate (hpc --fun-entry-count)
* tab width is now correct (markup was previously off in source with
tabs)
Internal changes
================
In Core, the Note constructor has been replaced by
Tick (Tickish b) (Expr b)
which is used to represent all the kinds of source annotation we
support: profiling SCCs, HPC ticks, and GHCi breakpoints.
Depending on the properties of the Tickish, different transformations
apply to Tick. See CoreUtils.mkTick for details.
Tickets
=======
This commit closes the following tickets, test cases to follow:
- Close #2552: not a bug, but the behaviour is now more intuitive
(test is T2552)
- Close #680 (test is T680)
- Close #1531 (test is result001)
- Close #949 (test is T949)
- Close #2466: test case has bitrotted (doesn't compile against current
version of vector-space package)
|
| |
|
|
|
|
|
|
|
|
| |
representation
This lets IfaceType be dumber, with fewer special cases, because deserialization for more
wired-in names will work. Once we have polymorphic kinds we will be able to replace IfaceTyCon
with a simple IfExtName.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
compiler/iface/BuildTyCl.lhs
compiler/iface/MkIface.lhs
compiler/iface/TcIface.lhs
compiler/typecheck/TcTyClsDecls.lhs
compiler/types/Class.lhs
compiler/utils/Util.lhs
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
this patch adds a new kind Constraint such that:
Show :: * -> Constraint
(?x::Int) :: Constraint
(Int ~ a) :: Constraint
And you can write *any* type with kind Constraint to the left of (=>):
even if that type is a type synonym, type variable, indexed type or so on.
The following (somewhat related) changes are also made:
1. We now box equality evidence. This is required because we want
to give (Int ~ a) the *lifted* kind Constraint
2. For similar reasons, implicit parameters can now only be of
a lifted kind. (?x::Int#) => ty is now ruled out
3. Implicit parameter constraints are now allowed in superclasses
and instance contexts (this just falls out as OK with the new
constraint solver)
Internally the following major changes were made:
1. There is now no PredTy in the Type data type. Instead
GHC checks the kind of a type to figure out if it is a predicate
2. There is now no AClass TyThing: we represent classes as TyThings
just as a ATyCon (classes had TyCons anyway)
3. What used to be (~) is now pretty-printed as (~#). The box
constructor EqBox :: (a ~# b) -> (a ~ b)
4. The type LCoercion is used internally in the constraint solver
and type checker to represent coercions with free variables
of type (a ~ b) rather than (a ~# b)
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically, now you can write:
class Cls a where
type Typ a
type Typ a = Just a
And now if an instance does not specify an explicit associated type
instance, one will be generated afresh based on that default. So for
example this instance:
instance Cls Int where
Will be equivalent to this one:
instance Cls Int where
type Typ Int = Just Int
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we compile -O0 we put type constructors in the interface file
without their data constructors -- an AbstractTyCon. But in a
client module, to give good pattern-match exhaustiveness warnings,
we need to know the difference between a data type and a newtype.
(The latter can be coerced to another type, but a data type can't.)
See Note [Pruning dead case alternatives] in Unify.
Because we weren't conveying this info, we were getting bogus
warnings about inexhaustive patterm matches with GADTs, and
(confusingly) these warnings woudl come and go depending on
whether you were compiling with -O.
This patch makes AbstractTyCon carry a flag indicating whether
the type constructor is "distinct"; two distinct TyCons cannot
be coerced into eachother (except by unsafeCoerce, in which case
all bets are off).
HEADS UP: interface file format changes slightly, so you need
to make clean.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently export list in .hi files are partitioned by module
export M T(C1,C2)
N f,g
In each list we only have OccNames, all assumed to come from
the parent module M or N resp.
This patch changes the representatation so that export lists
have full Names:
export M.T(M.C1,M.C2), N.f, N.g
Numerous advatages
* AvailInfo no longer needs to be parameterised; it always
contains Names
* Fixes Trac #5306. This was the main provocation
* Less to-and-fro conversion when reading interface files
It's all generally simpler. Interface files should not get bigger,
becuase they have a nice compact representation for Names.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being used.
We now track whether a module used any TH splices in the ModIface (and
at compile time in the TcGblEnv and ModGuts). If a module used TH
splices last time it was compiled, then we ignore the results of the
normal recompilation check and recompile anyway, *unless* the module
is "stable" - that is, none of its dependencies (direct or indirect)
have changed. The stability test is pretty important - otherwise ghc
--make would always recompile TH modules even if nothing at all had
changed, but it does require some extra plumbing to get this
information from GhcMake into HscMain.
test in driver/recomp009
|
|
|
|
| |
trustworthy module in the same package.
|
|
|
|
|
|
|
|
| |
This type was mainly there to support silent superclass
parameters for dfuns, and they have gone away. So this
patch is another minor simplification.
(Interface format change; you need to make clean.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduced silent superclass parameters as a way to avoid
superclass loops, but we now solve that problem a different
way ("derived" superclass constraints carry no evidence). So
they aren't needed any more.
Apart from being a needless complication, they broke DoCon.
Admittedly in a very obscure way, but still the result is
hard to explain. To see the details see Trac #5051, with
test case typecheck/should_compile/T5051. (The test is
nice and small!)
|
|
|
|
|
|
| |
For instance decls we no longer store the SafeHaskell mode
in this data structure but instead store it as a bool field
in the overlap flag structure.
|
| |
|
| |
|
|
|
|
| |
'HscTypes.VectInfo'.
|
|\
| |
| |
| |
| | |
Resolved conflicts:
compiler/typecheck/TcTyClsDecls.lhs
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
See the paper "Practical aspects of evidence based compilation in System FC"
* Coercion becomes a data type, distinct from Type
* Coercions become value-level things, rather than type-level things,
(although the value is zero bits wide, like the State token)
A consequence is that a coerion abstraction increases the arity by 1
(just like a dictionary abstraction)
* There is a new constructor in CoreExpr, namely Coercion, to inject
coercions into terms
|
|/
|
|
| |
handled, allow for standalone deriving of Representable0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch finally deals with the super-delicate question of
superclases in possibly-recursive dictionaries. The key idea
is the DFun Superclass Invariant (see TcInstDcls):
In the body of a DFun, every superclass argument to the
returned dictionary is
either * one of the arguments of the DFun,
or * constant, bound at top level
To establish the invariant, we add new "silent" superclass
argument(s) to each dfun, so that the dfun does not do superclass
selection internally. There's a bit of hoo-ha to make sure that
we don't print those silent arguments in error messages; a knock
on effect was a change in interface-file format.
A second change is that instead of the complex and fragile
"self dictionary binding" in TcInstDcls and TcClassDcl,
using the same mechanism for existential pattern bindings.
See Note [Subtle interaction of recursion and overlap] in TcInstDcls
and Note [Binding when looking up instances] in InstEnv.
Main notes are here:
* Note [Silent Superclass Arguments] in TcInstDcls,
including the DFun Superclass Invariant
Main code changes are:
* The code for MkId.mkDictFunId and mkDictFunTy
* DFunUnfoldings get a little more complicated;
their arguments are a new type DFunArg (in CoreSyn)
* No "self" argument in tcInstanceMethod
* No special tcSimplifySuperClasss
* No "dependents" argument to EvDFunApp
IMPORTANT
It turns out that it's quite tricky to generate the right
DFunUnfolding for a specialised dfun, when you use SPECIALISE
INSTANCE. For now I've just commented it out (in DsBinds) but
that'll lose some optimisation, and I need to get back to
this.
|