1. 15 Oct, 2018 11 commits
    • Ömer Sinan Ağacan's avatar
      Fix cardinality change of fields in addDataConStrictness · c5b477c2
      Ömer Sinan Ağacan authored
      Test Plan: This validates
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5225
      c5b477c2
    • Ryan Scott's avatar
      Fix #12430 by expanding type synonyms in injTyVarsOfType · 26e81e90
      Ryan Scott authored
      We weren't expanding type synonyms when determining the
      injective type variables of a type, leading to certain non-injective
      families being mistakenly labeled as injective (#12430). Easily fixed
      with a tactical use of `coreView`.
      
      Test Plan: make test TEST=T12430
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, carter
      
      GHC Trac Issues: #12430
      
      Differential Revision: https://phabricator.haskell.org/D5228
      26e81e90
    • Sasa Bogicevic's avatar
      Surprising error message with bang pattern · 0b0cb484
      Sasa Bogicevic authored
      Reviewers: bgamari, alanz
      
      Reviewed By: bgamari
      
      Subscribers: sgraf, mpickering, rwbarton, thomie, carter
      
      GHC Trac Issues: #13600
      
      Differential Revision: https://phabricator.haskell.org/D5040
      0b0cb484
    • Ben Gamari's avatar
      Typeable: Only render saturated tuple types with tuple syntax · 846fe904
      Ben Gamari authored
      This isn't as efficient as it could be since it needs to compute the
      kind of the type. However, this is `show` so there shouldn't be any
      particular expectation of speed.
      
      Fixes #14341.
      
      Test Plan: Validate
      
      Reviewers: hvr
      
      Subscribers: monoidal, rwbarton, carter
      
      GHC Trac Issues: #14341
      
      Differential Revision: https://phabricator.haskell.org/D5080
      846fe904
    • Krzysztof Gogolewski's avatar
      Cleanup boot and validate · a816ac48
      Krzysztof Gogolewski authored
      - Remove dph from validate; dph was removed
      - The required-tag argument to boot was used only for dph, remove
      - check_boot_packages() was not called at all, and didn't work.
        I fixed it based on previous Perl version.
      
      Test Plan: Harbormaster
      
      Reviewers: bgamari, thomie
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5129
      a816ac48
    • Tamar Christina's avatar
      Fix plugin tests requirements · 01c3d00a
      Tamar Christina authored
      Unfortunately the implementation has confused the ability to make
      dynamic libraries with dynamic way.
      This constraint is only true for systems that require `-fPIC` for
      shared libraries.
      
      Since the implementation has this implicit assumption, mark the tests
      as requiring dynway.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5174
      01c3d00a
    • Ben Gamari's avatar
      Deprecate -fllvm-pass-vectors-in-regs · 58dffa0a
      Ben Gamari authored
      Summary:
      The behavior previously enabled by this flag is as been the default
      since 8.6.1.
      
      Reviewers: simonmar
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5193
      58dffa0a
    • Nathan van Doorn's avatar
    • Ondra Pelech's avatar
    • Tobias Dammers's avatar
      Use an accumulator version of tyCoVarsOfType · 08b3db7e
      Tobias Dammers authored
      Summary:
      This is part 1 from #14880: factor out a worker for the tyCoVarsOf... family of
      function, implementing them in terms of VarSet, but with accumulator-style
      (like in `FV`) built in, and with the same kind of pre-insert lookup; this
      has shown to perform better than either FV or plain VarSet in this particular
      scenario.
      
      Original notes from simonpj:
      
      In TyCoRep we now have tyCoVarsOfType implemented
      
      1) Using FV -- this is the baseline version in GHC today
      
      2) Using VarSets via unionVarSet
      
      3) Using VarSets in accumulator-style
      
      In this patch (3) is enabled.
      
      When compiling perf/compiler/T5631 we get
      
               Compiler allocs
         (1)   1,144M
         (2)   1,175M
         (3)   1,142M
      
      The key new insight in (3) is this:
      
        ty_co_vars_of_type (TyVarTy v) is acc
          | v `elemVarSet` is  = acc
          | v `elemVarSet` acc = acc   <---- NB!
          | otherwise          = ty_co_vars_of_type (tyVarKind v) is (extendVarSet acc v)
      
      Notice the second line! If the variable is already in the
      accumulator, don't re-add it.  This makes big difference.
      Without it, allocation is 1,169M or so.
      
      One cause is that we only take the free vars of its kind once;
      that problem will go away when we do the main part of #14088 and
      close over kinds /afterwards/.  But still, another cause is perhaps
      that every insert into a set overwrites the previous item, and so
      allocates a new path to the item; it's not a no-op even if the
      item is there already.
      
      Why use (3) rather than (1)?  Becuase it just /has/ to
      be better;
      
      * FV carries around an InterestingVarFun, which does nothing
        useful here, but is tested at every variable
      
      * FV carries around a [Var] for the deterministic version.
      
      For this very hot operation (finding free vars) I think it
      makes sense to have speical purpose code.
      
      On the way I also simplified the (less used) coVarsOfType/Co family
      to use FV, by making serious use of the InterestingVarFun!
      
      Test Plan: validate, nofib
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #14880
      
      Differential Revision: https://phabricator.haskell.org/D5141
      08b3db7e
    • Ryan Scott's avatar
      Fix #15725 with an extra Sym · 48efbc04
      Ryan Scott authored
      Summary:
      We were adding a `Sym` to one argument in the `InstCo`
      case of `optCoercion` but not another, leading to the two arguments
      to misaligned when combined via `Trans`. This fixes the issue with
      a well targeted use of `wrapSym`.
      
      Test Plan: make test TEST=T15725
      
      Reviewers: goldfire, ningning, bgamari
      
      Reviewed By: goldfire, ningning
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15725
      
      Differential Revision: https://phabricator.haskell.org/D5217
      48efbc04
  2. 14 Oct, 2018 4 commits
  3. 12 Oct, 2018 3 commits
  4. 11 Oct, 2018 1 commit
    • Piyush P Kurur's avatar
      Support builtin classes like KnownNat in backpack · ce7a1c4a
      Piyush P Kurur authored
      This commit allows backpack signatures to enforce constraints like
      KnownNat
      on data types.  Thus it fixes #15379.  There were two important
      differences in the
      way GHC used to handle classes like KnowNat
      
      1.  Hand crafted instances of `KnownNat` were  forbidden, and
      
      2. The dictionary for an  instance `KnownNat T` was generated on the
      fly.
      
      For supporting backpack both these points have to be revisited.
      
      Disallowing instances of KnownNat
      --------------------------------------------
      
      Users were disallowed to declare instances of certain builtin classes
      like KnownNat for obvious safety reasons --- when we use the
      constraint like `KnownNat T`, we want T to be associated to a natural
      number. However, due to the reuse of this code while processing backpack
      signatures, `instance KnownNat T` were being disallowed even in module
      signature files.
      
      There is an important difference when it comes to instance declarations
      in a signature file. Consider the signature `Abstract` given below
      
      ```
      signature Abstract where
        data T :: Nat
        instance KnownNat T
      
      ```
      
      Inside a signature like `Abstract`, the `instance Known T` is not really
      creating an instance but rather demanding any module that implements
      this signature to enforce the constraint `KnownNat` on its type
      T.  While hand crafted KnownNat instances continued to be prohibited in
      modules,
      this commit ensures that it is not forbidden while handling signatures.
      
      Resolving Dictionaries
      ----------------------------
      
      Normally GHC expects any instance `T` of class `KnownNat` to eventually
      resolve
      to an integer and hence used to generate the evidence/dictionary for
      such instances
      on the fly as in when it is required. However, when backpack module and
      signatures are involved
      It is not always possible to resolve the type to a concrete integer
      utill the mixin stage. To illustrate
      consider again the  signature `Abstract`
      
      > signature Abstract where
      >   data T :: Nat
      >   instance KnownNat T
      
      and a module `Util` that depends on it:
      
      > module Util where
      >     import Abstract
      >     printT :: IO ()
      >     printT = do print $ natVal (Proxy :: Proxy T)
      
      Clearly, we need to "use" the dictionary associated with `KnownNat T`
      in the module `Util`, but it is too early for the compiler to produce
      a real dictionary as we still have not fixed what `T` is. Only when we
      mixin a concrete module
      
      > module Concrete where
      >   type T = 42
      
      do we really get hold of the underlying integer.
      
      In this commit, we make the following changes in the resolution of
      instance dictionary
      for constraints like `KnownNat T`
      
      1. If T is indeed available as a type alias for an integer constant,
         generate the dictionary on the fly as before, failing which
      
      2. Do not give up as before but look up the type class environment for
      the evidence.
      
      This was enough to make the resolution of `KnownNat` dictionaries work
      in the setting of Backpack as
      when actual code is generated, the signature Abstract (due to the
      `import Abstract` ) in `Util` gets
      replaced by an actual module like Concrete, and resolution happens as
      before.
      
      Everything that we said for `KnownNat` is applicable for `KnownSymbol`
      as well.
      
      Reviewers: bgamari, ezyang, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, ezyang, rwbarton, thomie, carter
      
      GHC Trac Issues: #15379
      
      Differential Revision: https://phabricator.haskell.org/D4988
      ce7a1c4a
  5. 10 Oct, 2018 2 commits
    • Ömer Sinan Ağacan's avatar
      Re-enable test T14251 · 2f693b3e
      Ömer Sinan Ağacan authored
      (This change was accidentally reverted with the previous commit)
      2f693b3e
    • Ömer Sinan Ağacan's avatar
      Fix dataToTag# argument evaluation · ac977688
      Ömer Sinan Ağacan authored
      See #15696 for more details. We now always enter dataToTag# argument (done in
      generated Cmm, in StgCmmExpr). Any high-level optimisations on dataToTag#
      applications are done by the simplifier. Looking at tag bits (instead of
      reading the info table) for small types is left to another diff.
      
      Incorrect test T14626 is removed. We no longer do this optimisation (see
      comment:44, comment:45, comment:60).
      
      Comments and notes about special cases around dataToTag# are removed. We no
      longer have any special cases around it in Core.
      
      Other changes related to evaluating primops (seq# and dataToTag#) will be
      pursued in follow-up diffs.
      
      Test Plan: Validates with three regression tests
      
      Reviewers: simonpj, simonmar, hvr, bgamari, dfeuer
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15696
      
      Differential Revision: https://phabricator.haskell.org/D5201
      ac977688
  6. 09 Oct, 2018 2 commits
  7. 07 Oct, 2018 5 commits
  8. 06 Oct, 2018 2 commits
  9. 05 Oct, 2018 8 commits
  10. 04 Oct, 2018 2 commits
    • Ryan Scott's avatar
      Don't leak internal commentary into HasField's Haddocks · 89656c21
      Ryan Scott authored
      In commit 2f09753f, some internal comments about the kind
      signature of the HasField class accidentially leaked into its
      publicly exported Haddocks.
      89656c21
    • Alec Theriault's avatar
      Set `infixr -1 ->` · 251e3424
      Alec Theriault authored
      Summary:
      This simply makes explicit what is already the case. Due to special
      treatment in the parser, `->` has the lowest fixity. This patch propagates
      that information to:
      
        * GHCi, where `:info ->` now return the right fixity
        * TH, where `reifyFixity` returns the right fixity
        * the generated sources for `GHC.Prim`
      
      See #15235.
      
      Test Plan: make test
      
      Reviewers: bgamari, alanz, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: int-index, RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15235
      
      Differential Revision: https://phabricator.haskell.org/D5199
      251e3424