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. 24 Oct, 2016 4 commits
    • Simon Peyton Jones's avatar
      Test Trac #12081 · 853cdaea
      Simon Peyton Jones authored
      853cdaea
    • Simon Peyton Jones's avatar
      Test Trac #12174 · 03b0b8e4
      Simon Peyton Jones authored
      03b0b8e4
    • Simon Peyton Jones's avatar
      Take account of kinds in promoteTcType · 08ba691a
      Simon Peyton Jones authored
      One of the ASSERT failures in Trac #12762, namely the one for T4439,
      showed that I had not dealt correctly with promoting the kind of
      a type in promoteTcType.
      
      Happily I could fix this by simplifying InferRes (eliminating the
      ir_kind field), so things get better. And the ASSERT is fixed.
      08ba691a
    • Simon Peyton Jones's avatar
      Prioritise class-level equality costraints · 1c4a39d3
      Simon Peyton Jones authored
      This patch fixes Trac #12734 by prioritising the class-level
      variants of equality constraints, namely (a~b) and (a~~b).
      
      See comment:10 of Trac #12734 for a description of what
      went wrong, and Note [Prioritise class equalities] in TcSMonad.
      
      The fix is still not great, but it's a definite step forward, and
      cures the particular problem.
      
      Worth merging to 8.0.
      1c4a39d3
  2. 22 Oct, 2016 3 commits
    • Erik de Castro Lopo's avatar
      Add -Wcpp-undef warning flag · 3cb32d8b
      Erik de Castro Lopo authored and Ben Gamari's avatar Ben Gamari committed
      When enabled, this new warning flag passes `-Wundef` to the C
      pre-processor which causes the pre-processor to warn on uses of
      the `#if` directive on undefined identifiers.
      
      It is not currently enabled in any of the standard warning groups.
      
      Test Plan: Make sure the two tests pass on all major platforms.
      
      Reviewers: hvr, carter, Phyx, bgamari, austin
      
      Reviewed By: Phyx
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2626
      
      GHC Trac Issues: #12752
      3cb32d8b
    • Matthew Pickering's avatar
      Skip T5611 on OSX as it fails non-deterministically. · a662f46c
      Matthew Pickering authored and Ben Gamari's avatar Ben Gamari committed
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2622
      
      GHC Trac Issues: #12751
      a662f46c
    • Simon Marlow's avatar
      Fix failure in setnumcapabilities001 (#12728) · acc98510
      Simon Marlow authored and Ben Gamari's avatar Ben Gamari committed
      The value of enabled_capabilities can change across a call to
      requestSync(), and we were erroneously using an old value, causing
      things to go wrong later.  It manifested as an assertion failure, I'm
      not sure whether there are worse consequences or not, but we should
      get this fix into 8.0.2 anyway.
      
      The failure didn't happen for me because it only shows up on machines
      with fewer than 4 processors, due to the new logic to enable -qn
      automatically.  I've bumped the test parameter 8 to make it more
      likely to exercise that code.
      
      Test Plan: Ran setnumcapabilities001 many times
      
      Reviewers: niteria, austin, erikd, rwbarton, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2617
      
      GHC Trac Issues: #12728
      acc98510
  3. 21 Oct, 2016 4 commits
    • Simon Peyton Jones's avatar
      Accept 20% dedgradation in Trac #5030 compile time · 1f09b246
      Simon Peyton Jones authored
      In commit
      
        31621b12 * A collection of type-inference refactorings.
      
      I fixed a bug in the on-the-fly unifier.  Usually the
      on-the-fly unifier (TcUnify) defers type function
      applications to the constraint solver.  But in one situation
      it inconsistently did not defer, so a unification happened
      without reducing a type function.  By a fluke this makes
      T5030 (specifcially the definition of cnst) much better.
      
      It turns out that consistently non-deferring type functions
      makes the test for #3064 go bad.  So somehow the current,
      inconsistent situation was an accidental sweet spot.
      
      But it's a horrible sweet spot, relying on what was essentially
      a bug.  So I've accepted the worsening (it's an exotic case),
      and opened #12724 to deal with the underlying cause.
      1f09b246
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. Add a TcLevel to SkolemTvs. This will be useful generally
      
          - it's a fast way to see if the type
            variable escapes when floating (not used yet)
      
          - it provides a good consistency check when updating a
            unification variable (TcMType.writeMetaTyVarRef, the
            level_check_ok check)
      
         I originally had another reason (related to the flirting
         in (2), but I left it in because it seems like a step in
         the right direction.
      
      5. Reduce and simplify the plethora of uExpType,
         tcSubType and related functions in TcUnify.  It was
         such an opaque mess and it's still not great, but it's
         better.
      
      6. Simplify the uo_expected field of TypeEqOrigin.  Richard
         had generatlised it to a ExpType, but it was almost always
         a Check type.  Now it's back to being a plain TcType which
         is much, much easier.
      
      7. Improve error messages by refraining from skolemisation when
         it's clear that there's an error: see
         TcUnify Note [Don't skolemise unnecessarily]
      
      8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
         so I added it
      
      9. Kill off tcs_used_tcvs.  Its purpose is to track the
         givens used by wanted constraints.  For dictionaries etc
         we do that via the free vars of the /bindings/ in the
         implication constraint ic_binds.  But for coercions we
         just do update-in-place in the type, rather than
         generating a binding.  So we need something analogous to
         bindings, to track what coercions we have added.
      
         That was the purpose of tcs_used_tcvs.  But it only
         worked for a /single/ iteration, whereas we may have
         multiple iterations of solving an implication.  Look
         at (the old) 'setImplicationStatus'.  If the constraint
         is unsolved, it just drops the used_tvs on the floor.
         If it becomes solved next time round, we'll pick up
         coercions used in that round, but ignore ones used in
         the first round.
      
         There was an outright bug.  Result = (potentialy) bogus
         unused-constraint errors.  Constructing a case where this
         actually happens seems quite trick so I did not do so.
      
         Solution: expand EvBindsVar to include the (free vars of
         the) coercions, so that the coercions are tracked in
         essentially the same way as the bindings.
      
         This turned out to be much simpler.  Less code, more
         correct.
      
      10. Make the ic_binds field in an implication have type
            ic_binds :: EvBindsVar
          instead of (as previously)
             ic_binds :: Maybe EvBindsVar
          This is notably simpler, and faster to use -- less
          testing of the Maybe.  But in the occaional situation
          where we don't have anywhere to put the bindings, the
          belt-and-braces error check is lost.  So I put it back
          as an ASSERT in 'setImplicationStatus' (see the use of
          'termEvidenceAllowed')
      
      All these changes led to quite bit of error message wibbling
      3f5673f3
    • Simon Peyton Jones's avatar
      Test Trac #12507 · cdbc73ae
      Simon Peyton Jones authored
      This is now working apparently.  It relates to when a
      polymorphic function gets instantiated, under some
      implicit paramter bindings.
      cdbc73ae
    • Simon Peyton Jones's avatar
      Refactor typechecking of pattern bindings · 45bfd1a6
      Simon Peyton Jones authored
      This patch fixes a regression introduced, post 8.0.1, by
      this major commit:
      
           commit 15b9bf4b
           Author: Simon Peyton Jones <simonpj@microsoft.com>
           Date:   Sat Jun 11 23:49:27 2016 +0100
      
               Improve typechecking of let-bindings
      
               This major commit was initially triggered by #11339, but it
               spiraled into a major review of the way in which type
               signatures for bindings are handled, especially partial type
               signatures.
      
      I didn't get the typechecking of pattern bindings right, leading
      to Trac #12427.
      
      In fixing this I found that this program doesn't work:
      
        data T where
          T :: a -> ((forall b. [b]->[b]) -> Int) -> T
      
        h1 y = case y of T _ v -> v
      
      Works in 7.10, but not in 8.0.1.
      
      There's a happy ending. I found a way to fix this, and improve
      pattern bindings too.  Not only does this fix #12427, but it also
      allows
      
      In particular,we now can accept
      
        data T where MkT :: a -> Int -> T
      
        ... let { MkT _ q = t } in ...
      
      Previously this elicited "my head exploded" but it's really
      fine since q::Int.
      
      The approach is described in detail in TcBinds
         Note [Typechecking pattern bindings]
      Super cool.  And not even a big patch!
      45bfd1a6
  4. 20 Oct, 2016 3 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Support constraint synonym implementations of abstract classes. · 7e77c4b2
      Edward Z. Yang authored
      Summary:
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2595
      
      GHC Trac Issues: #12679
      7e77c4b2
    • Edward Z. Yang's avatar
      New story for abstract data types in hsig files. · 518f2895
      Edward Z. Yang authored
      
      
      Summary:
      In the old implementation of hsig files, we directly
      reused the implementation of abstract data types from
      hs-boot files.  However, this was WRONG.  Consider the
      following program (an abridged version of bkpfail24):
      
          {-# LANGUAGE GADTs #-}
          unit p where
              signature H1 where
                  data T
              signature H2 where
                  data T
              module M where
                  import qualified H1
                  import qualified H2
      
                  f :: H1.T ~ H2.T => a -> b
                  f x = x
      
      Prior to this patch, M was accepted, because the type
      inference engine concluded that H1.T ~ H2.T does not
      hold (indeed, *presently*, it does not).  However, if
      we subsequently instantiate p with the same module for
      H1 and H2, H1.T ~ H2.T does hold!  Unsound.
      
      The key is that abstract types from signatures need to
      be treated like *skolem variables*, since you can interpret
      a Backpack unit as a record which is universally quantified
      over all of its abstract types, as such (with some fake
      syntax for structural records):
      
          p :: forall t1 t2. { f :: t1 ~ t2 => a -> b }
          p = { f = \x -> x } -- ill-typed
      
      Clearly t1 ~ t2 is not solvable inside p, and also clearly
      it could be true at some point in the future, so we better
      not treat the lambda expression after f as inaccessible.
      
      The fix seems to be simple: do NOT eagerly fail when trying
      to simplify the given constraints.  Instead, treat H1.T ~ H2.T
      as an irreducible constraint (rather than an insoluble
      one); this causes GHC to treat f as accessible--now we will
      typecheck the rest of the function (and correctly fail).
      Per the OutsideIn(X) paper, it's always sound to fail less
      when simplifying givens.
      
      We do NOT apply this fix to hs-boot files, where abstract
      data is also guaranteed to be nominally distinct (since
      it can't be implemented via a reexport or a type synonym.)
      This is a somewhat unnatural state of affairs (there's
      no way to really interpret this in Haskell land) but
      no reason to change behavior.
      
      I deleted "representationally distinct abstract data",
      which is never used anywhere in GHC.
      
      In the process of constructing this fix, I also realized
      our implementation of type synonym matching against abstract
      data was not sufficiently restrictive.  In order for
      a type synonym T to be well-formed type, it must be a
      nullary synonym (i.e., type T :: * -> *, not type T a = ...).
      Furthermore, since we use abstract data when defining
      instances, they must not have any type family applications.
      
      More details in #12680.  This probably deserves some sort
      of short paper report.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2594
      518f2895
  5. 19 Oct, 2016 2 commits
  6. 18 Oct, 2016 2 commits
  7. 17 Oct, 2016 10 commits
  8. 15 Oct, 2016 1 commit
  9. 14 Oct, 2016 4 commits
    • Michael Snoyman's avatar
      Disable T-signals-child test on single-threaded runtime · 0d9524a8
      Michael Snoyman authored and Ben Gamari's avatar Ben Gamari committed
      As identified by Joachim, this test broke the Travis build. It appears
      that this is due to the usage of the single-threaded runtime there. I've
      confirmed that this fix causes the Travis build to pass:
      https://travis-ci.org/snoyberg/ghc/builds/167368988.
      
      Test Plan: Confirm tests now pass
      
      Reviewers: austin, nomeata, bgamari
      
      Reviewed By: nomeata, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2593
      0d9524a8
    • Sylvain HENRY's avatar
      Check for empty entity string in "prim" foreign imports · 6c739326
      Sylvain HENRY authored and Ben Gamari's avatar Ben Gamari committed
      Foreign imports with "prim" convention require a valid symbol identifier
      (see linked issue). We check this.
      
      Fix line too long
      
      Test Plan: Validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2563
      
      GHC Trac Issues: #12355
      6c739326
    • Ryan Scott's avatar
      Make error when deriving an instance for a typeclass less misleading · d5a4e49d
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Before, when you attempted to derive an instance for a typeclass,
      e.g.,
      
      ```
      class C1 (a :: Constraint) where
      class C2 where
      
      deriving instance C1 C2
      ```
      
      GHC would complain that `C2`'s data constructors aren't in scope. But
      that
      makes no sense, since typeclasses don't have constructors! By refining
      the
      checks that GHC performs when deriving, we can make the error message a
      little more sensible.
      
      This also cleans up a related `DeriveAnyClass` infelicity. Before, you
      wouldn't have been able to compile code like this:
      
      ```
      import System.IO (Handle)
      class C a
      deriving instance C Handle
      ```
      
      Since GHC was requiring that all data constructors of `Handle` be in
      scope. But `DeriveAnyClass` doesn't even generate code that mentions
      any data constructors, so this requirement is silly!
      
      Fixes #11509.
      
      Test Plan: make test TEST=T11509
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2558
      
      GHC Trac Issues: #11509
      d5a4e49d
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  10. 13 Oct, 2016 3 commits
  11. 12 Oct, 2016 4 commits