1. 21 Sep, 2015 2 commits
    • Edward Z. Yang's avatar
      Unify hsig and hs-boot; add preliminary "hs-boot" merging. · 06d46b1e
      Edward Z. Yang authored
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, spinda
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1098
      06d46b1e
    • Edward Z. Yang's avatar
      3f13c20e
  2. 03 Sep, 2015 1 commit
  3. 06 Aug, 2015 1 commit
    • Ben Gamari's avatar
      Ensure DynFlags are consistent · eca9a1a1
      Ben Gamari authored
      While we have always had makeDynFlagsConsistent to enforce a variety of
      consistency invariants on DynFlags, it hasn't been widely used.
      GHC.Main, for instance, ignored it entirely. This leads to issues like
      Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency,
      leading to a perplexing crash later in compilation.
      
      Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags,
      closing this hole.
      
      Fixes #10549.
      
      Test Plan: Validate with T10549
      
      Reviewers: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1128
      
      GHC Trac Issues: #10549
      eca9a1a1
  4. 21 Jul, 2015 1 commit
  5. 12 Jun, 2015 1 commit
    • Simon Marlow's avatar
      Add parseExpr and compileParsedExpr and use them in GHC API and GHCi · d20031d4
      Simon Marlow authored
      Summary:
      This commit brings following changes and fixes:
      
       * Implement parseExpr and compileParsedExpr;
       * Fix compileExpr and dynCompilerExpr, which returned `()` for empty expr;
       * Fix :def and :cmd, which didn't work if `IO` or `String` is not in scope;
       * Use GHCiMonad instead IO in :def and :cmd;
       * Clean PrelInfo: delete dead comment and duplicate entries, add assertion.
      
      See new tests for more details.
      
      Test Plan: ./validate
      
      Reviewers: austin, dterei, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D974
      
      GHC Trac Issues: #10508
      d20031d4
  6. 11 Jun, 2015 1 commit
  7. 02 Jun, 2015 1 commit
    • Austin Seipp's avatar
      compiler: make sure we reject -O + HscInterpreted · 091944e3
      Austin Seipp authored
      When using GHCi, we explicitly reject optimization, because the
      compilers optimization passes can introduce unboxed tuples, which the
      interpreter is not able to handle. But this goes the other way too: using
      GHCi on optimized code may cause the optimizer to float out breakpoints
      that the interpreter introduces. This manifests itself in weird ways,
      particularly if you as an API client use custom DynFlags to introduce
      optimization in combination with HscInterpreted.
      
      It turns out we weren't checking for consistent DynFlag settings when
      doing `setSessionDynFlags`, as #10052 showed. While the main driver
      handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
      elsewhere.
      
      This does a little refactoring to split out some of the common code, and
      immunizes the various `DynFlags` utilities in the `GHC` module from this
      particular bug. We should probably be checking other general invariants
      too.
      
      This fixes #10052, and adds some notes about the behavior in `GHC` and
      `FloatOut`
      
      As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
      didn't exist (somehow).
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: edsko
      
      Differential Revision: https://phabricator.haskell.org/D727
      
      GHC Trac Issues: #10052
      091944e3
  8. 19 May, 2015 2 commits
    • Austin Seipp's avatar
      Revert "compiler: make sure we reject -O + HscInterpreted" (again) · edb8dc5c
      Austin Seipp authored
      Apparently my machine likes this commit, but Harbormaster does not?
      
      This reverts commit b199536b.
      edb8dc5c
    • Austin Seipp's avatar
      compiler: make sure we reject -O + HscInterpreted · b199536b
      Austin Seipp authored
      When using GHCi, we explicitly reject optimization, because the
      compilers optimization passes can introduce unboxed tuples, which the
      interpreter is not able to handle. But this goes the other way too: using
      GHCi on optimized code may cause the optimizer to float out breakpoints
      that the interpreter introduces. This manifests itself in weird ways,
      particularly if you as an API client use custom DynFlags to introduce
      optimization in combination with HscInterpreted.
      
      It turns out we weren't checking for consistent DynFlag settings when
      doing `setSessionDynFlags`, as #10052 showed. While the main driver
      handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
      elsewhere.
      
      This does a little refactoring to split out some of the common code, and
      immunizes the various `DynFlags` utilities in the `GHC` module from this
      particular bug. We should probably be checking other general invariants
      too.
      
      This fixes #10052, and adds some notes about the behavior in `GHC` and
      `FloatOut`
      
      As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
      didn't exist (somehow).
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: edsko
      
      Differential Revision: https://phabricator.haskell.org/D727
      
      GHC Trac Issues: #10052
      b199536b
  9. 13 May, 2015 1 commit
    • Austin Seipp's avatar
      Revert D727 · 8764a7e8
      Austin Seipp authored
      This caused print007 to fail, so I guess I botched this more than I
      thought. This is a combination of reverting:
      
        "Fix build breakage from 9736c042", commit f35d621d.
        "compiler: make sure we reject -O + HscInterpreted", commit 9736c042.
      8764a7e8
  10. 12 May, 2015 1 commit
  11. 11 May, 2015 2 commits
    • Austin Seipp's avatar
      compiler: make sure we reject -O + HscInterpreted · 9736c042
      Austin Seipp authored
      When using GHCi, we explicitly reject optimization, because the
      compilers optimization passes can introduce unboxed tuples, which the
      interpreter is not able to handle. But this goes the other way too: using
      GHCi on optimized code may cause the optimizer to float out breakpoints
      that the interpreter introduces. This manifests itself in weird ways,
      particularly if you as an API client use custom DynFlags to introduce
      optimization in combination with HscInterpreted.
      
      It turns out we weren't checking for consistent DynFlag settings when
      doing `setSessionDynFlags`, as #10052 showed. While the main driver
      handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
      elsewhere.
      
      This does a little refactoring to split out some of the common code, and
      immunizes the various `DynFlags` utilities in the `GHC` module from this
      particular bug. We should probably be checking other general invariants
      too.
      
      This fixes #10052, and adds some notes about the behavior in `GHC` and
      `FloatOut`
      
      As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
      didn't exist (somehow).
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: edsko
      
      Differential Revision: https://phabricator.haskell.org/D727
      
      GHC Trac Issues: #10052
      9736c042
    • Simon Marlow's avatar
      More accurate allocation stats for :set +s · cf7573b8
      Simon Marlow authored
      The point of this commit is to make the memory allocation statistic
      from :set +s in GHCi a lot more accurate.  Currently it uses the total
      allocation figure calculated by the RTS, which is only updated during
      GC, so can be wrong by an arbitrary amount.  The fix is to the the
      per-thread allocation counter that was introduced for allocation
      limits.
      
      This required changes to the GHC API, because we now have to return
      the allocation value from each evaluation.  Rather than just change
      the API, I introduced a new API and deprecated the old one.  The new
      one is simpler and more extensible, so hopefully we won't need to make
      this transition in the future.  See GHC.hs for details.
      cf7573b8
  12. 07 Apr, 2015 1 commit
    • Edward Z. Yang's avatar
      Support for multiple signature files in scope. · a7524eae
      Edward Z. Yang authored
      Summary:
      A common pattern when programming with signatures is to combine multiple
      signatures together (signature linking).  We achieve this by making it
      not-an-error to have multiple, distinct interface files for the same module
      name, as long as they have the same backing implementation.  When a user
      imports a module name, they get ALL matching signatures dumped into their
      scope.
      
      On the way, I refactored the module finder code, which now distinguishes
      between exact finds (when you had a 'Module') and regular finds (when
      you had a 'ModuleName').  I also refactored the package finder code to
      use a Monoid instance on LookupResult to collect together various results.
      
      ToDo: At the moment, if a signature is declared in the local package,
      it completely overrides any remote signatures.  Eventually, we'll want
      to also pull in the remote signatures (or even override the local signature,
      if the full implementation is available.)  There are bunch of ToDos in the
      code for what to do once this is done.
      
      ToDo: At the moment, whenever a module name lookup occurs in GHCi and we
      would have seen a signature, we instead continue and return the Module
      for the backing implementation.  This is correct for most cases, but there
      might be some situations where we want something a little more fine-grained
      (e.g. :browse should only list identifiers which are available through
      the in-scope signatures, and not ALL of them.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, hvr, austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D790
      
      GHC Trac Issues: #9252
      a7524eae
  13. 10 Feb, 2015 1 commit
  14. 16 Jan, 2015 1 commit
    • Alan Zimmerman's avatar
      API Annotations tweaks. · 11881ec6
      Alan Zimmerman authored
      Summary:
      HsTyLit now has SourceText
      
      Update documentation of HsSyn to reflect which annotations are attached to which element.
      
      Ensure that the parser always keeps HsSCC and HsTickPragma values, to
      be ignored in the desugar phase if not needed
      
      Bringing in SourceText for pragmas
      
      Add Location in NPlusKPat
      
      Add Location in FunDep
      
      Make RecCon payload Located
      
      Explicitly add AnnVal to RdrName where it is compound
      
      Add Location in IPBind
      
      Add Location to name in IEThingAbs
      
      Add Maybe (Located id,Bool) to Match to track fun_id,infix
        This includes converting Match into a record and adding a note about why
        the fun_id needs to be replicated in the Match.
      
      Add Location in KindedTyVar
      
      Sort out semi-colons for parsing
      
        - import statements
        - stmts
        - decls
        - decls_cls
        - decls_inst
      
      This updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D538
      11881ec6
  15. 09 Jan, 2015 1 commit
  16. 08 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Improve HsBang · 9564bb8c
      Simon Peyton Jones authored
      Provoked by questions from Johan
      
       - Improve comments, fix misleading stuff
       - Add commented synonyms for HsSrcBang, HsImplBang, and use them throughout
       - Rename HsUserBang to HsSrcBang
       - Rename dataConStrictMarks to dataConSrcBangs
                dataConRepBangs    to dataConImplBangs
      
      This renaming affects Haddock in a trivial way, hence submodule update
      9564bb8c
  17. 06 Jan, 2015 1 commit
  18. 28 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rename some of the functions in NameSet, to make the uniform with VarSet etc · 7460dafa
      Simon Peyton Jones authored
      For ages NameSet has used different names,
        eg.   addOneToNameSet   rather than    extendNameSet
              nameSetToList     rather than    nameSetElems
      
      etc.  Other set-like modules use uniform naming conventions.
      This patch makes NameSet follow suit.
      
      No change in behaviour; this is just renaming.
      
      I'm doing this just before the fork so that merging is easier.
      7460dafa
  19. 21 Nov, 2014 1 commit
    • Alan Zimmerman's avatar
      Add API Annotations · 803fc5db
      Alan Zimmerman authored
      Summary:
      The final design and discussion is captured at
      https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
      
      This is a proof of concept implementation of a completely
      separate annotation structure, populated in the parser,and tied to the
      AST by means of a virtual "node-key" comprising the surrounding
      SrcSpan and a value derived from the specific constructor used for the
      node.
      
      The key parts of the design are the following.
      
      == The Annotations ==
      
      In `hsSyn/ApiAnnotation.hs`
      
      ```lang=haskell
      type ApiAnns = (Map.Map ApiAnnKey SrcSpan, Map.Map SrcSpan [Located Token])
      
      type ApiAnnKey = (SrcSpan,AnnKeywordId)
      
      -- ---------------------------------------------------------------------
      
      -- | Retrieve an annotation based on the @SrcSpan@ of the annotated AST
      -- element, and the known type of the annotation.
      getAnnotation :: ApiAnns -> SrcSpan -> AnnKeywordId -> Maybe SrcSpan
      getAnnotation (anns,_) span ann = Map.lookup (span,ann) anns
      
      -- |Retrieve the comments allocated to the current @SrcSpan@
      getAnnotationComments :: ApiAnns -> SrcSpan -> [Located Token]
      getAnnotationComments (_,anns) span =
        case Map.lookup span anns of
          Just cs -> cs
          Nothing -> []
      
      -- | Note: in general the names of these are taken from the
      -- corresponding token, unless otherwise noted
      data AnnKeywordId
               = AnnAs
               | AnnBang
               | AnnClass
               | AnnClose -- ^ } or ] or ) or #) etc
               | AnnComma
               | AnnDarrow
               | AnnData
               | AnnDcolon
               ....
      ```
      
      == Capturing in the lexer/parser ==
      
      The annotations are captured in the lexer / parser by extending PState to include a field
      
      In `parser/Lexer.x`
      
      ```lang=haskell
      data PState = PState {
              ....
              annotations :: [(ApiAnnKey,SrcSpan)]
              -- Annotations giving the locations of 'noise' tokens in the
              -- source, so that users of the GHC API can do source to
              -- source conversions.
           }
      ```
      
      The lexer exposes a helper function to add an annotation
      
      ```lang=haskell
      addAnnotation :: SrcSpan -> Ann -> SrcSpan -> P ()
      addAnnotation l a v = P $ \s -> POk s {
        annotations = ((AK l a), v) : annotations s
        } ()
      
      ```
      
      The parser also has some helper functions of the form
      
      ```lang=haskell
      type MaybeAnn = Maybe (SrcSpan -> P ())
      
      gl = getLoc
      gj x = Just (gl x)
      
      ams :: Located a -> [MaybeAnn] -> P (Located a)
      ams a@(L l _) bs = (mapM_ (\a -> a l) $ catMaybes bs) >> return a
      ```
      
      This allows annotations to be captured in the parser by means of
      
      ```
      ctypedoc :: { LHsType RdrName }
              : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >>
                                                  ams (LL $ mkExplicitHsForAllTy $2 (noLoc []) $4)
                                                      [mj AnnForall $1,mj AnnDot $3] }
              | context '=>' ctypedoc         {% ams (LL $ mkQualifiedHsForAllTy   $1 $3)
                                                     [mj AnnDarrow $2] }
              | ipvar '::' type               {% ams (LL (HsIParamTy (unLoc $1) $3))
                                                     [mj AnnDcolon $2] }
              | typedoc                       { $1 }
      ```
      
      == Parse result ==
      
      ```lang-haskell
      data HsParsedModule = HsParsedModule {
          hpm_module    :: Located (HsModule RdrName),
          hpm_src_files :: [FilePath],
             -- ^ extra source files (e.g. from #includes).  The lexer collects
             -- these from '# <file> <line>' pragmas, which the C preprocessor
             -- leaves behind.  These files and their timestamps are stored in
             -- the .hi file, so that we can force recompilation if any of
             -- them change (#3589)
          hpm_annotations :: ApiAnns
        }
      
      -- | The result of successful parsing.
      data ParsedModule =
        ParsedModule { pm_mod_summary   :: ModSummary
                     , pm_parsed_source :: ParsedSource
                     , pm_extra_src_files :: [FilePath]
                     , pm_annotations :: ApiAnns }
      ```
      
      This diff depends on D426
      
      Test Plan: sh ./validate
      
      Reviewers: austin, simonpj, Mikolaj
      
      Reviewed By: simonpj, Mikolaj
      
      Subscribers: Mikolaj, goldfire, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D438
      
      GHC Trac Issues: #9628
      803fc5db
  20. 20 Nov, 2014 1 commit
    • Jan Stolarek's avatar
      Split SynTyCon to SynonymTyCon and FamilyTyCon · 696fc4ba
      Jan Stolarek authored
      This patch refactors internal representation of type synonyms and type families by splitting them into two separate data constructors of TyCon data type. The main motivation is is that some fields make sense only for type synonyms and some make sense only for type families. This will be even more true with the upcoming injective type families.
      
      There is also some refactoring of names to keep the naming constistent. And thus tc_kind field has become tyConKind and tc_roles has become tcRoles. Both changes are not visible from the outside of TyCon module.
      
      Updates haddock submodule
      
      Reviewers: simonpj
      
      Differential Revision: https://phabricator.haskell.org/D508
      
      GHC Trac Issues: #9812
      696fc4ba
  21. 05 Aug, 2014 1 commit
  22. 26 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Module reexports, fixing #8407. · 7f5c1086
      Edward Z. Yang authored
      The general approach is to add a new field to the package database,
      reexported-modules, which considered by the module finder as possible
      module declarations.  Unlike declaring stub module files, multiple
      reexports of the same physical package at the same name do not
      result in an ambiguous import.
      
      Has submodule updates for Cabal and haddock.
      
      NB: When a reexport renames a module, that renaming is *not* accessible
      from inside the package.  This is not so much a deliberate design choice
      as for implementation expediency (reexport resolution happens only when
      a package is in the package database.)
      
      TODO: Error handling when there are duplicate reexports/etc is not very
      well tested.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	testsuite/.gitignore
      	utils/haddock
      7f5c1086
  23. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  24. 03 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Do pretty-printing of TyThings via IfaceDecl (Trac #7730) · b4856f9f
      Simon Peyton Jones authored
      All the initial work on this was done fy 'archblob' (fcsernik@gmail.com);
      thank you!
      
      I reviewed the patch, started some tidying, up and then ended up in a huge
      swamp of changes, not all of which I can remember now.  But:
      
      * To suppress kind arguments when we have -fno-print-explicit-kinds,
          - IfaceTyConApp argument types are in a tagged list IfaceTcArgs
      
      * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType.
      
      * When printing data/type family instances for the user, I've made them
        print out an informative RHS, which is a new feature. Thus
              ghci> info T
              data family T a
              data instance T Int = T1 Int Int
              data instance T Bool = T2
      
      * In implementation terms, pprIfaceDecl has just one "context" argument,
        of type IfaceSyn.ShowSub, which says
             - How to print the binders of the decl
               see note [Printing IfaceDecl binders] in IfaceSyn
             - Which sub-comoponents (eg constructors) to print
      
      * Moved FastStringEnv from RnEnv to OccName
      
      It all took a ridiculously long time to do.  But it's done!
      b4856f9f
  25. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  26. 03 May, 2014 1 commit
  27. 19 Apr, 2014 1 commit
  28. 13 Mar, 2014 1 commit
  29. 28 Jan, 2014 2 commits
  30. 10 Jan, 2014 1 commit
  31. 14 Nov, 2013 1 commit
    • Duncan Coutts's avatar
      Don translate UserInterrupt into ExitFailure 1, let it propagate · 12cdd6da
      Duncan Coutts authored
      It is important that if a program recieved ^C from the user, and the
      program terminates as a result, that it exit with SIGINT so that the
      parent process knows that was the case. For example cabal calling ghc
      will then be able to tell the difference between it failing and the user
      interrupting with ^C and report (or not) appropriately.
      
      So we should just let the UserInterrupt exception propagate to the top
      level error handler which will do the right thing.
      
      See http://www.cons.org/cracauer/sigint.html
      12cdd6da
  32. 02 Nov, 2013 1 commit
  33. 22 Sep, 2013 1 commit
  34. 21 Jun, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Revise implementation of overlapping type family instances. · 569b2652
      eir@cis.upenn.edu authored
      This commit changes the syntax and story around overlapping type
      family instances. Before, we had "unbranched" instances and
      "branched" instances. Now, we have closed type families and
      open ones.
      
      The behavior of open families is completely unchanged. In particular,
      coincident overlap of open type family instances still works, despite
      emails to the contrary.
      
      A closed type family is declared like this:
      > type family F a where
      >   F Int = Bool
      >   F a   = Char
      The equations are tried in order, from top to bottom, subject to
      certain constraints, as described in the user manual. It is not
      allowed to declare an instance of a closed family.
      569b2652
  35. 26 Apr, 2013 2 commits