This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 18 Dec, 2014 1 commit
  2. 17 Dec, 2014 1 commit
  3. 03 Dec, 2014 1 commit
  4. 28 Nov, 2014 1 commit
  5. 21 Nov, 2014 2 commits
  6. 20 Nov, 2014 2 commits
    • Jan Stolarek's avatar
      Kill trailing whitespace · e2f78036
      Jan Stolarek authored
      e2f78036
    • 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
  7. 04 Nov, 2014 2 commits
  8. 31 Oct, 2014 1 commit
  9. 24 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Implementation of hsig (module signatures), per #9252 · aa479953
      Edward Z. Yang authored
      
      
      Summary:
      Module signatures, like hs-boot files, are Haskell modules which omit
      value definitions and contain only signatures.  This patchset implements
      one particular aspect of module signature, namely compiling them against
      a concrete implementation.  It works like this: when we compile an hsig
      file, we must be told (via the -sig-of flag) what module this signature
      is implementing.  The signature is compiled into an interface file which
      reexports precisely the entities mentioned in the signature file.  We also
      verify that the interface is compatible with the implementation.
      
      This feature is useful in a few situations:
      
          1. Like explicit import lists, signatures can be used to reduce
          sensitivity to upstream changes.  However, a signature can be defined
          once and then reused by many modules.
      
          2. Signatures can be used to quickly check if a new upstream version
          is compatible, by typechecking just the signatures and not the actual
          modules.
      
          3. A signature can be used to mediate separate modular development,
          where the signature is used as a placeholder for functionality which
          is loaded in later.  (This is only half useful at the moment, since
          typechecking against signatures without implementations is not implemented
          in this patchset.)
      
      Unlike hs-boot files, hsig files impose no performance overhead.
      
      This patchset punts on the type class instances (and type families) problem:
      instances simply leak from the implementation to the signature.  You can
      explicitly specify what instances you expect to have, and those will be checked,
      but you may get more instances than you asked for.  Our eventual plan is
      to allow hiding instances, but to consider all transitively reachable instances
      when considering overlap and soundness.
      
      ToDo: signature merging: when a module is provided by multiple signatures
      for the same base implementation, we should not consider this ambiguous.
      
      ToDo: at the moment, signatures do not constitute use-sites, so if you
      write a signature for a deprecated function, you won't get a warning
      when you compile the signature.
      
      Future work: The ability to feed in shaping information so that we can take
      advantage of more type equalities than might be immediately evident.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate and new tests
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D130
      
      GHC Trac Issues: #9252
      aa479953
  10. 07 Oct, 2014 1 commit
  11. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      
      
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  12. 06 Sep, 2014 1 commit
  13. 12 Aug, 2014 2 commits
    • eir@cis.upenn.edu's avatar
      Remove NonParametricKinds (#9200) · 578377ce
      eir@cis.upenn.edu authored
      This commit also removes 'KindCheckingStrategy' and related gubbins,
      instead including the notion of a CUSK into HsDecls.
      578377ce
    • eir@cis.upenn.edu's avatar
      Fix #9415. · 1b138869
      eir@cis.upenn.edu authored
      Abort typechecking when we detect a superclass cycle error, as
      ambiguity checking in the presence of superclass cycle errors can
      cause a loop.
      1b138869
  14. 15 Jul, 2014 1 commit
    • Simon Peyton Jones's avatar
      Entirely re-jig the handling of default type-family instances (fixes Trac #9063) · 9b8ba629
      Simon Peyton Jones authored
      In looking at Trac #9063 I decided to re-design the default
      instances for associated type synonyms.  Previously it was all
      jolly complicated, to support generality that no one wanted, and
      was arguably undesirable.
      
      Specifically
      
      * The default instance for an associated type can have only
        type variables on the LHS.  (Not type patterns.)
      
      * There can be at most one default instances declaration for
        each associated type.
      
      To achieve this I had to do a surprisingly large amount of refactoring
      of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
      of the LHS patterns.
      
      That change in HsDecls has a (trivial) knock-on effect in Haddock, so
      this commit does a submodule update too.
      
      The net result is good though.  The code is simpler; the language
      specification is simpler.  Happy days.
      
      Trac #9263 and #9264 are thereby fixed as well.
      9b8ba629
  15. 01 Jul, 2014 1 commit
  16. 11 Jun, 2014 2 commits
  17. 09 Jun, 2014 1 commit
  18. 06 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Make the matcher and wrapper Ids in PatSyn into LocalIds, not GlobalIds · 7ac600d5
      Simon Peyton Jones authored
      This was a serious bug, exposed by Trac #9175.  The matcher and wrapper
      must be LocalIds, like record selectors and dictionary functions, for
      the reasons now documented in Note [Exported LocalIds] in Id.lhs
      
      In fixing this I found
       - PatSyn should have an Id inside it (apart from the wrapper and matcher)
         It should be a Name.  Hence psId --> psName, with knock-on consequences
      
       - Tidying of PatSyns in TidyPgm was wrong
      
       - The keep-alive set in Desugar.deSugar (now) doesn't need pattern synonyms
         in it
      
      I also cleaned up the interface to PatSyn a little, so there's a tiny knock-on
      effect in Haddock; hence the haddock submodule update.
      
      It's very hard to make a test for this bug, so I haven't.
      7ac600d5
  19. 04 Jun, 2014 1 commit
  20. 03 Jun, 2014 1 commit
  21. 15 May, 2014 2 commits
    • Simon Peyton Jones's avatar
      Refactoring around TyCon.isSynTyCon · 022f8750
      Simon Peyton Jones authored
      * Document isSynTyCon better
      * Add isTypeSyonymTyCon for regular H98 type synonyms
      * Use isTypeSynonymTyCon rather than isSynTyCon where
        the former is really intended
      
      All arose as part of a bug I introduced when fixing Trac #9102,
      thinking that isSynTyCon meant H98 type syononyms.
      022f8750
    • 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
  22. 08 May, 2014 1 commit
  23. 13 Apr, 2014 1 commit
  24. 05 Apr, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #8958. · d468cd37
      eir@cis.upenn.edu authored
      We now do role inference on stupid datatype contexts, allowing a
      lightweight role annotation syntax.
      d468cd37
  25. 23 Mar, 2014 1 commit
  26. 13 Mar, 2014 1 commit
  27. 13 Feb, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #8773. · 13829758
      eir@cis.upenn.edu authored
      To make a role annotation on a class asserting a role other than
      nominal, you now need -XIncoherentInstances. See the ticket for
      more information as to why this is a good idea.
      13829758
  28. 20 Jan, 2014 1 commit
    • Gergő Érdi's avatar
      Implement pattern synonyms · 4f8369bf
      Gergő Érdi authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      
      The rundown is this:
      
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
      
        * Unidirectional patterns are declared like thus:
      
              pattern P x <- x:_
      
          The synonym 'P' may only occur in a pattern context:
      
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
      
        * Bidirectional patterns are declared like thus:
      
              pattern P x y = [x, y]
      
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
      
              bar :: Int -> [Int]
              bar x = P x 10
      
        * Patterns can't yet have their own type signatures; signatures are inferred.
      
        * Pattern synonyms may not be recursive, c.f. type synonyms.
      
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
      
              module Foo (pattern Bar) where ...
      
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
      
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
      
              pattern P x y <- [x, y]
      
              f (P True True) = True
              f _             = False
      
              g [True, True] = True
              g _            = False
      
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      
      For more information, see the wiki:
      
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation
      
      Reviewed-by: default avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      4f8369bf
  29. 05 Dec, 2013 1 commit
  30. 02 Dec, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Rejig rejigConRes & friends, doing role checks in a second pass. · 40673406
      eir@cis.upenn.edu authored
      This commit is just a refactoring, intended to make the use of
      rejigConRes (which sorts out the return types of GADT-like constructors)
      less delicate. The idea is that, if we perform role checking in a
      second top-level pass, we can use checkValidDataCon to check for
      valid return types. Previously, checking roles would force the
      rejigConRes thunk before we knew that rejigConRes was safe to call!
      40673406
  31. 22 Nov, 2013 1 commit
    • Simon Peyton Jones's avatar
      A raft of changes driven by Trac #8540 · 78814882
      Simon Peyton Jones authored
      The root cause of #8450 is that the new Template Haskell story, with
      the renamer doing more of the work of Template Haskell, wasn't dealing
      correctly with the keepAlive problem.  Consider
          g = ..blah...
          f = [| g |]
      Then f's RHS refers to g's name but not to g, so g was being discarded
      as dead code.
      
      Fixing this sucked me into a deep swamp of understanding how all the moving
      parts of hte new Template Haskell fit together, leading to a large collection
      of related changes and better documentation.  Specifically:
      
      * Instead of putting the TH level of a binder in the LocalRdrEnv, there
        is now a separate field
            tcl_th_bndrs :: NameEnv (TopLevelFlag, ThLevel)
        in the TcLclEnv, which records for each binder
           a) whether it is syntactically a top-level binder or not
           b) its TH level
        This deals uniformly with top-level and non-top-level binders, which was
        previously dealt with via greviously-delicate meddling with Internal and
        External Names.  Much better.
      
      * As a result I could remove the tct_level field of ATcId.
      
      * There are consequential changes in TcEnv too, which must also extend the
        level bindings.  Again, more clarity.
      
        I renamed TcEnv.tcExtendTcTyThingEnv to tcExtendKindEnv2, since it's only used
        during kind inference, for (AThing kind) and APromotionErr; and that is
        relevant to whether we want to extend the tcl_th_bndrs field (no).
      
      * I de-crufted the code in RnEnv.extendGlobalRdrEnv, by getting rid of the
        qual_gre code which said "Seems like 5 times as much work as it deserves!".
        Instead, RdrName.pickGREs makes the Internal names shadow External ones.
      
      * I moved the checkThLocalName cross-stage test to finishHsVar; previously
        we weren't doing the test at all in the OpApp case!
      
      * Quite a few changes (shortening the code) in the cross-stage checking code
        in TcExpr and RnSplice, notably to move the keepAlive call to the renamer
      
      One leftover piece:
      
      * In TcEnv I removed tcExtendGhciEnv and refactored
        tcExtendGlobalTyVars; this is really related to the next commit, but
        it was too hard to disentangle.
      78814882
  32. 04 Oct, 2013 2 commits
    • Simon Peyton Jones's avatar
      Simplify the plumbing for checkValidTyCl · 17457791
      Simon Peyton Jones authored
      Instead of walking over the source decls, and looking up the Name
      to find the TyCon or whatever, we just walk over the list of
      TyThings that have been brought into scope.  This is much tidier.
      
      The only wrinkle is that, since we don't have the original declaration,
      we don't have its SrcSpan to put in the error message.  I fixed this
      by making the SrcSpan for the TyCon itself be the span of the whole
      declaration.  This actually makes sense anyway.
      
      There are bunch of error message wibbles in consequence.
      17457791
    • Simon Peyton Jones's avatar
      Comments and white space only · 8d829544
      Simon Peyton Jones authored
      8d829544
  33. 03 Oct, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Fix Trac #8368. · 0c7d2d75
      eir@cis.upenn.edu authored and Krzysztof Gogolewski's avatar Krzysztof Gogolewski committed
      Two different fixes were necessary here. First, we need to fail eagerly
      in kcConDecl, to prevent the return-type error in tcConDecl from firing
      twice. (This wasn't caught earlier because of the eager fail in the
      datatype kind-checking code -- which isn't used for data instances!)
      We also must check again in tcDataFamInstDecl, because it's possible for
      a data instance return type to have the right head but the wrong body
      (i.e., doesn't conform to the data instance type patterns). This check
      is only possible *after* desugaring from HsType to Type, so it can't be
      done in tcConRes with the first check.
      
      This is documented in a comment at check_valid_data_con, a local
      function within tcDataFamInstDecl.
      0c7d2d75