| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| | |
* Vectorisation avoidance is now the default
* Types and values from unvectorised modules are permitted in scalar code
* Simplified the VECTORISE pragmas (see http://hackage.haskell.org/trac/ghc/wiki/DataParallel/VectPragma for the spec)
* Vectorisation information is now included in the annotated Core AST
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Conflicts:
compiler/types/Coercion.lhs
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
The idea is that you can use "_foo" rather than just "_"
as a "hole" in an expression, and this name shows up in
type errors etc.
The changes are very straightforward.
Thanks for Thijs Alkemade for making the running here.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Make MatchGroup into a record, and use the record fields
* Split the type field into two: mg_arg_tys and mg_res_ty
This makes life much easier for the desugarer when the
case alterantives are empty
A little bit of this change unavoidably ended up in the preceding
commit about empty case alternatives
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The main changes are:
* Parser accepts empty case alternatives
* Renamer checks that -XEmptyCase is on in that case
* (Typechecker is pretty much unchanged.)
* Desugarer desugars empty case alternatives, esp:
- Match.matchWrapper and Match.match now accept empty eqns
- New function matchEmpty deals with the empty case
- See Note [Empty case alternatives] in Match
This patch contains most of the work, but it's a bit mixed up
with a refactoring of MatchGroup that I did at the same time
(next commit).
|
| |/ / |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An ordered, overlapping type family instance is introduced by 'type
instance
where', followed by equations. See the new section in the user manual
(7.7.2.2) for details. The canonical example is Boolean equality at the
type
level:
type family Equals (a :: k) (b :: k) :: Bool
type instance where
Equals a a = True
Equals a b = False
A branched family instance, such as this one, checks its equations in
order
and applies only the first the matches. As explained in the note
[Instance
checking within groups] in FamInstEnv.lhs, we must be careful not to
simplify,
say, (Equals Int b) to False, because b might later unify with Int.
This commit includes all of the commits on the overlapping-tyfams
branch. SPJ
requested that I combine all my commits over the past several months
into one
monolithic commit. The following GHC repos are affected: ghc, testsuite,
utils/haddock, libraries/template-haskell, and libraries/dph.
Here are some details for the interested:
- The definition of CoAxiom has been moved from TyCon.lhs to a
new file CoAxiom.lhs. I made this decision because of the
number of definitions necessary to support BranchList.
- BranchList is a GADT whose type tracks whether it is a
singleton list or not-necessarily-a-singleton-list. The reason
I introduced this type is to increase static checking of places
where GHC code assumes that a FamInst or CoAxiom is indeed a
singleton. This assumption takes place roughly 10 times
throughout the code. I was worried that a future change to GHC
would invalidate the assumption, and GHC might subtly fail to
do the right thing. By explicitly labeling CoAxioms and
FamInsts as being Unbranched (singleton) or
Branched (not-necessarily-singleton), we make this assumption
explicit and checkable. Furthermore, to enforce the accuracy of
this label, the list of branches of a CoAxiom or FamInst is
stored using a BranchList, whose constructors constrain its
type index appropriately.
I think that the decision to use BranchList is probably the most
controversial decision I made from a code design point of view.
Although I provide conversions to/from ordinary lists, it is more
efficient to use the brList... functions provided in CoAxiom than
always to convert. The use of these functions does not wander far
from the core CoAxiom/FamInst logic.
BranchLists are motivated and explained in the note [Branched axioms] in
CoAxiom.lhs.
- The CoAxiom type has changed significantly. You can see the new
type in CoAxiom.lhs. It uses a CoAxBranch type to track
branches of the CoAxiom. Correspondingly various functions
producing and consuming CoAxioms had to change, including the
binary layout of interface files.
- To get branched axioms to work correctly, it is important to have a
notion
of type "apartness": two types are apart if they cannot unify, and no
substitution of variables can ever get them to unify, even after type
family
simplification. (This is different than the normal failure to unify
because
of the type family bit.) This notion in encoded in tcApartTys, in
Unify.lhs.
Because apartness is finer-grained than unification, the tcUnifyTys
now
calls tcApartTys.
- CoreLinting axioms has been updated, both to reflect the new
form of CoAxiom and to enforce the apartness rules of branch
application. The formalization of the new rules is in
docs/core-spec/core-spec.pdf.
- The FamInst type (in types/FamInstEnv.lhs) has changed
significantly, paralleling the changes to CoAxiom. Of course,
this forced minor changes in many files.
- There are several new Notes in FamInstEnv.lhs, including one
discussing confluent overlap and why we're not doing it.
- lookupFamInstEnv, lookupFamInstEnvConflicts, and
lookup_fam_inst_env' (the function that actually does the work)
have all been more-or-less completely rewritten. There is a
Note [lookup_fam_inst_env' implementation] describing the
implementation. One of the changes that affects other files is
to change the type of matches from a pair of (FamInst, [Type])
to a new datatype (which now includes the index of the matching
branch). This seemed a better design.
- The TySynInstD constructor in Template Haskell was updated to
use the new datatype TySynEqn. I also bumped the TH version
number, requiring changes to DPH cabal files. (That's why the
DPH repo has an overlapping-tyfams branch.)
- As SPJ requested, I refactored some of the code in HsDecls:
* splitting up TyDecl into SynDecl and DataDecl, correspondingly
changing HsTyDefn to HsDataDefn (with only one constructor)
* splitting FamInstD into TyFamInstD and DataFamInstD and
splitting FamInstDecl into DataFamInstDecl and TyFamInstDecl
* making the ClsInstD take a ClsInstDecl, for parallelism with
InstDecl's other constructors
* changing constructor TyFamily into FamDecl
* creating a FamilyDecl type that stores the details for a family
declaration; this is useful because FamilyDecls can appear in classes
but
other decls cannot
* restricting the associated types and associated type defaults for a
* class
to be the new, more restrictive types
* splitting cid_fam_insts into cid_tyfam_insts and cid_datafam_insts,
according to the new types
* perhaps one or two more that I'm overlooking
None of these changes has far-reaching implications.
- The user manual, section 7.7.2.2, is updated to describe the new type
family
instances.
|
| | | |
|
| | |
| |
| |
| |
| | |
We were mixing up the *implicit* import of Prelude
with a user-written import declaration
|
| | |
| |
| |
| | |
Fixes Trac #7404
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
See Note [Newtype constructor usage in foreign declarations] in TcForeign.
It's quite non-trivial to say which newtype constructor are used in
foreign import/export declarations, and I had to do a bit of refactoring
to achieve it. (Say hello to the X5 bus from Oxford to Cambridge.)
It's a bit tiresome, with some more plumbing, but not hard.
Trac #7048 triggered this change.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Occurrences in terms are uses, in patterns they are not.
In this way we get unused-constructor warnings from modules like this
module M( f, g, T ) where
data T = T1 | T2 Bool
f x = T2 x
g T1 = True
g (T2 x) = x
Here a T1 value cannot be constructed, so we can warn. The use
in a pattern doesn't count. See Note [Patterns are not uses]
in RnPat.
Interestingly this change exposed three module in GHC itself
that had unused constructors, which I duly removed:
* ghc/Main.hs
* compiler/ghci/ByteCodeAsm
* compiler/nativeGen/PPC/RegInfo
Their changes are in this patch.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
Mostly d -> g (matching DynFlag -> GeneralFlag).
Also renamed if* to when*, matching the Haskell if/when names
|
| |/ /
| |
| |
| | |
Fixes Trac #7338
|
| | |
| |
| |
| | |
patch submitted by marcotmarcot@gmail.com
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All the work was done by Dan Winograd-Cort.
The main thing is that arrow comamnds now have their own
data type HsCmd (defined in HsExpr). Previously it was
punned with the HsExpr type, which was jolly confusing,
and made it hard to do anything arrow-specific.
To make this work, we now parameterise
* MatchGroup
* Match
* GRHSs, GRHS
* StmtLR and friends
over the "body", that is the kind of thing they
enclose. This "body" parameter can be instantiated to
either LHsExpr or LHsCmd respectively.
Everything else is really a knock-on effect; there should
be no change (yet!) in behaviour. But it should be a sounder
basis for fixing bugs.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
We only warn when the method is used, not when it is defined as part
of an instance.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This single commit combines a lot of work done by
Thijs Alkemade <thijsalkemade@gmail.com>, plus a slew
of subsequent refactoring by Simon PJ.
The basic idea is
* Add a new expression form "_", a hole, standing for a not-yet-written expression
* Give a useful error message that
(a) gives the type of the hole
(b) gives the types of some enclosing value bindings that
mention the hole
Driven by this goal I did a LOT of refactoring in TcErrors, which in turn
allows us to report enclosing value bindings for other errors, not just
holes. (Thijs rightly did not attempt this!)
The major data type change is a new form of constraint
data Ct = ...
| CHoleCan {
cc_ev :: CtEvidence,
cc_hole_ty :: TcTauType,
cc_depth :: SubGoalDepth }
I'm still in two minds about whether this is the best plan. Another
possibility would be to have a predicate type for holes, somthing like
class Hole a where
holeValue :: a
It works the way it is, but there are some annoying special cases for
CHoleCan (just grep for "CHoleCan").
|
| |/ /
| |
| |
| |
| |
| | |
There's a very very wrong piece of code in TcArrows;
and it is even triggering an ASERT failure now. I need
to talk to Ross to figure out what is going on.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
Also fix a bug where a dodgy import warning was emitted for data
families with a single constructor.
|
| |/ /
| |
| |
| |
| | |
All the mechanism was there, but it wasn't being use for the
name-shadowing test.
|
| | |
| |
| |
| | |
Fixes Trac #7164
|
| | |
| |
| |
| | |
Fixes Trac #7151
|
| |/ |
|
| |
|
|
|
|
|
|
| |
_ = e
Thse are used in a few libraries, either to add type constraints
via a signature, or to mention some variables that are only
otherwise mentioned in one #ifdef branch
|
| |\ |
|
| | |
| |
| |
| | |
Fixes Trac #7085
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |\
| |
| |
| |
| | |
Fix conflicts in:
compiler/main/DynFlags.hs
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Summary:
- mdo expressions are enabled by RecursiveDo pragma
- mdo expressions perform full segmentation
- 'rec' groups inside 'do' are changed so they do *not*
perform any segmentation.
- Both 'mdo' and 'rec' are enabled by 'RecursiveDo'
'DoRec' is deprecated in favour of 'RecursiveDo'
(The 'rec' keyword is also enabled by 'Arrows', as now.)
Thanks to Levent for doing all the work
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
Previously (Trac #6148) we were only complaining for the
distfix syntax (a,b,c).
|
