1. 26 Oct, 2016 7 commits
  2. 25 Oct, 2016 1 commit
  3. 24 Oct, 2016 5 commits
  4. 23 Oct, 2016 1 commit
  5. 22 Oct, 2016 9 commits
    • Matthew Pickering's avatar
      a6bcf878
    • Erik de Castro Lopo's avatar
      rts/package.conf.in: Fix CPP usage · aaede1ec
      Erik de Castro Lopo authored
      Summary:
      The configure script sets `HAVE_LIBNUMA` to either `0` or `1` but this
      file had `#ifdef HAVE_LIBNUMA`. This surfaced as a side-effect of
      1050e46b. CPP is really hard to get right.
      
      Test Plan: Validate on harbourmaster
      
      Reviewers: simonmar, bgamari, austin, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2631
      aaede1ec
    • Michal Terepeta's avatar
      cmm/Hoopl/Dataflow: minor cleanup · b76cf04e
      Michal Terepeta authored
      This doesn't have any functional changes, it simply removes one
      unnecessary top binding and improves the comments.
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2619
      b76cf04e
    • Matthew Pickering's avatar
      Refactoring: Delete copied function in backpack/NameShape · 6e9a51c0
      Matthew Pickering authored
      Also moved a few utility functions which work with Avails into
      the Avail module to avoid import loops and increase discoverability.
      
      Reviewers: austin, bgamari, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2629
      6e9a51c0
    • Erik de Castro Lopo's avatar
      Add -Wcpp-undef warning flag · 3cb32d8b
      Erik de Castro Lopo authored
      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
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2622
      
      GHC Trac Issues: #12751
      a662f46c
    • Darshan Kapashi's avatar
      rts: configure.ac should populate HAVE_LIBNUMA instead of USE_LIBNUMA · 1050e46b
      Darshan Kapashi authored
      Code in rts/ which deals with numa checks for `#if HAVE_LIBNUMA`,
      however this macro is not populated during `./configure`.
      https://phabricator.haskell.org/D2329 changed this code last and we
      instead set `USE_LIBNUMA` which fails to setup numa correctly.
      
      Test Plan:
      From main directory in ghc,
      
        ./configure && make clean && make boot && make
        cd nofib/parallel/queens
        ../../../inplace/bin/ghc-stage2 Main.hs -rtsopts -threaded
        ./Main 15 +RTS -N24 -s -A64m --numa
      
      This fails before this patch with
      
        Main: --numa: OS reports NUMA is not available
      
      After the fix, it works as expected.
      
      Run the validation script,
      
        ./validate
      
      (It fails with an error in `compiler/utils/Util.hs` saying
      `GHC.Stack.CallStack` not found, once I remove this 1 line from this
      file , the script works)
      
      Reviewers: hvr, austin, bgamari, erikd, simonmar
      
      Reviewed By: erikd, simonmar
      
      Subscribers: mpickering, thomie, erikd, niteria
      
      Differential Revision: https://phabricator.haskell.org/D2620
      
      GHC Trac Issues: #12741
      1050e46b
    • Simon Marlow's avatar
      Fix failure in setnumcapabilities001 (#12728) · acc98510
      Simon Marlow authored
      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
    • Duncan Coutts's avatar
      Add and use a new dynamic-library-dirs field in the ghc-pkg info · f41a8a36
      Duncan Coutts authored
      Summary:
      Build systems / package managers want to be able to control the file
      layout of installed libraries. In general they may want/need to be able
      to put the static libraries and dynamic libraries in different places.
      The ghc-pkg library regisrtation needs to be able to handle this.
      
      This is already possible in principle by listing both a static lib dir
      and a dynamic lib dir in the library-dirs field (indeed some previous
      versions of Cabal did this for shared libs on ELF platforms).
      
      The downside of listing both dirs is twofold. There is a lack of
      precision, if we're not careful with naming then we could end up
      picking up the wrong library. The more immediate problem however is
      that if we list both directories then both directories get included
      into the ELF and Mach-O shared object runtime search paths. On ELF this
      merely slows down loading of shared libs (affecting prog startup time).
      On the latest OSX versions this provokes a much more serious problem:
      that there is a rather low limit on the total size of the section
      containing the runtime search path (and lib names and related) and thus
      listing any unnecessary directories wastes the limited space.
      
      So the solution in this patch is fairly straightforward: split the
      static and dynamic library search paths in the ghc-pkg db and its use
      within ghc. This is a traditional solution: pkg-config has the same
      static / dynamic split (though it describes in in terms of private and
      public, but it translates into different behaviour for static and
      dynamic linking).
      
      Indeed it would make perfect sense to also have a static/dynamic split
      for the list of the libraries to use i.e. to have dynamic variants of
      the hs-libraries and extra-libraries fields. These are not immediately
      required so this patch does not add it, but it is a reasonable
      direction to follow.
      
      To handle compatibility, if the new dynamic-library-dirs field is not
      specified then its value is taken from the library-dirs field.
      
      Contains Cabal submodule update.
      
      Test Plan:
      Run ./validate
      
      Get christiaanb and carter to test it on OSX Sierra, in combination
      with Cabal/cabal-install changes to the default file layout for
      libraries.
      
      Reviewers: carter, austin, hvr, christiaanb, bgamari
      
      Reviewed By: christiaanb, bgamari
      
      Subscribers: ezyang, Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2611
      
      GHC Trac Issues: #12479
      f41a8a36
  6. 21 Oct, 2016 10 commits
    • Simon Peyton Jones's avatar
      Improve TcCanonical.unifyWanted and unifyDerived · 6ddba642
      Simon Peyton Jones authored
      When debugging something else I noticed that these functions
      were emitting constraints like
         [W] a ~ a
      which is plain stupid.  So I fixed it not to do that.  Should
      result in fewer constraints getting generated.
      6ddba642
    • Simon Peyton Jones's avatar
      Define emitNewWantedEq, and use it · e1fc5a33
      Simon Peyton Jones authored
      This is just a minor refactoring
      e1fc5a33
    • Simon Peyton Jones's avatar
      Refactor occurrence-check logic · 9417e579
      Simon Peyton Jones authored
      This patch does two related things
      
      * Combines the occurrence-check logic in the on-the-fly unifier with
        that in the constraint solver.  They are both doing the same job,
        after all.  The resulting code is now in TcUnify:
           metaTyVarUpdateOK
           occCheckExpand
           occCheckForErrors (called in TcErrors)
      
      * In doing this I disovered checking for family-free-ness and foralls
        can be unnecessarily inefficient, because it expands type synonyms.
        It's easy just to cache this info in the type syononym TyCon, which
        I am now doing.
      9417e579
    • 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
      Make TcLevel increase by 1 not 2 · d61c7e8d
      Simon Peyton Jones authored
      Make the TcLevel of a flatten-meta-var be always zero.
      See TcType.fmvTcLevel.
      
      This allows the levels of implication constraints to to
      up by 1 each time instead of 2, which is less confusing.
      
      This change has no effect on type checking.
      d61c7e8d
    • 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
      Comments and trivial refactoring · 82efad78
      Simon Peyton Jones authored
      82efad78
    • 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
    • Gabor Greif's avatar
      Typos in comments · ff225b49
      Gabor Greif authored
      ff225b49
  7. 20 Oct, 2016 6 commits
    • Ben Gamari's avatar
      check-cpp: Make it more robust · c23dc616
      Ben Gamari authored
      Catch more than one space
      c23dc616
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Only delete instances when merging when there is an exact match. · 9df4ce4f
      Edward Z. Yang authored
      Summary:
      Previously, we deleted if the heads matched, which meant that
      we effectively were picking an arbitrary instance if there
      were incompatible instances.  The new behavior makes more sense,
      although without incoherent instances you are unlikely to
      be able to do anything useful with the instances.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2596
      9df4ce4f
    • 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
  8. 19 Oct, 2016 1 commit