1. 10 Jun, 2018 4 commits
  2. 09 Jun, 2018 1 commit
  3. 08 Jun, 2018 6 commits
  4. 07 Jun, 2018 21 commits
    • Iavor S. Diatchki's avatar
      Allow Haddock comments before function arguments. · 200c8e04
      Iavor S. Diatchki authored and Ben Gamari's avatar Ben Gamari committed
      Currently, documentation strings on function arguments has to be written
      after the argument (i.e., using `{-^ -}` comments).  This patch allows
      us to use `{-| -}` comments to put the comment string before an
      argument.   The same works for the results of functions.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4767
      200c8e04
    • Matthew Pickering's avatar
      Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc · dc8c03b2
      Matthew Pickering authored and Ben Gamari's avatar Ben Gamari committed
      The primary motivation for this is that this allows users to access
      the warnings and error machinery present in TcM. However, it also allows
      users to use TcM actions which means they can typecheck GhcPs which
      could be significantly easier than constructing GhcTc.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15229
      
      Differential Revision: https://phabricator.haskell.org/D4792
      dc8c03b2
    • Matthew Pickering's avatar
      Rename dataConRepNameUnique to dataConTyRepNameUnique · fa34ced5
      Matthew Pickering authored and Ben Gamari's avatar Ben Gamari committed
      The `DataCon` rep also applies to the worker. For example, see
      `MkId.mkDataConRep`.  `dataConTyRepNameUnique` is for the type
      representation, so we rename it to make this distinction clear.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4797
      fa34ced5
    • Ben Gamari's avatar
      rts: Fix reference to srt_bitmap in ASSERT in RetainerProfile · 838cb53a
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Test Plan: Validate
      
      Reviewers: erikd, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4798
      838cb53a
    • Ryan Scott's avatar
      Fix #15236 by removing parentheses from funTyConName · 3397396a
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Currently, `funTyConName` is defined as:
      
      ```lang=haskell
      funTyConName = mkPrimTyConName (fsLit "(->)") funTyConKey funTyCon
      ```
      
      What's strange about this definition is that there are extraneous
      parentheses around `->`, which is quite unlike every other infix
      `Name`. As a result, the `:info (->)` output is totally garbled (see
      Trac #15236).
      
      It's quite straightforward to fix that particular bug by removing the
      extraneous parentheses. However, it turns out that this makes some
      test output involving `Show` instances for `TypeRep` look less
      appealing, since `->` is no longer surrounded with parentheses when
      applied prefix. But neither were any /other/ infix type constructors!
      The right fix there was to change `showTypeable` to put parentheses
      around prefix applications of infix tycons.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15236
      
      Differential Revision: https://phabricator.haskell.org/D4799
      3397396a
    • Ryan Scott's avatar
      Don't expose (~#), (~R#), (~P#) from GHC.Prim · 5926b6ed
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Currently, the primitive `(~#)`, `(~R#)`, and `(~P#)` type
      constructors are wired in to be exported from `GHC.Prim`. This has
      some unfortunate consequences, however. It turns out that `(~#)` is
      actually a legal infix identifier, so users can make use of unboxed
      equalities in strange ways in user code (see #15209). The other two,
      `(~R#)` and `(~P#)`, can't be used in source code, but they can be
      observed with GHCi's `:browse` command, which is somewhat unnerving.
      
      The fix for both of these problems is simple: just don't wire them
      to be exported from `GHC.Prim`.
      
      Test Plan: make test TEST="T12023 T15209"
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: rwbarton, thomie, carter, dfeuer
      
      GHC Trac Issues: #12023, #15209
      
      Differential Revision: https://phabricator.haskell.org/D4801
      5926b6ed
    • Ben Gamari's avatar
      testsuite: Skip T13838 in ghci way · 04e29fc6
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Test Plan: `make slowtest TEST=T13838`
      
      Reviewers: alpmestan, dfeuer
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #15238
      
      Differential Revision: https://phabricator.haskell.org/D4802
      04e29fc6
    • Ryan Scott's avatar
      Document #15079 in the users' guide · bc9a838a
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Trac #15079 revealed an interesting limitation in the interaction
      between variable visibility and higher-rank kinds. We (Richard and I)
      came to the conclusion that this is an acceptable (albeit surprising)
      limitation, so this documents in the users' guide to hopefully eliminate
      some confusion for others in the future.
      
      Test Plan: Read it
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15079
      
      Differential Revision: https://phabricator.haskell.org/D4803
      bc9a838a
    • Ryan Scott's avatar
      Fix #15243 by fixing incorrect uses of NotPromoted · 569c16a7
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      In `Convert`, we were incorrectly using `NotPromoted` to
      denote type constructors that were actually intended to be promoted,
      resulting in poor `-ddump-splices` output (as seen in #15243).
      Easily fixed.
      
      Test Plan: make test TEST=T15243
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15243
      
      Differential Revision: https://phabricator.haskell.org/D4809
      569c16a7
    • Ben Gamari's avatar
      testsuite: Add test for #15232 · 5026840f
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15232
      
      Differential Revision: https://phabricator.haskell.org/D4807
      5026840f
    • Alec Theriault's avatar
      Move 'HsBangTy' out in constructor arguments · 0361fc03
      Alec Theriault authored and Ben Gamari's avatar Ben Gamari committed
      When run with -haddock, a constructor argument can have both a a
      strictness/unpackedness annotation and a docstring. The parser binds
      'HsBangTy' more tightly than 'HsDocTy', yet for constructor arguments we
      really need the 'HsBangTy' on the outside.
      
      This commit does this shuffling in the 'mkConDeclH98' and 'mkGadtDecl'
      smart constructors.
      
      Test Plan: haddockA038, haddockC038
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: bgamari
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4727
      0361fc03
    • Andreas Klebinger's avatar
      Check if both branches of an Cmm if have the same target. · efea32cf
      Andreas Klebinger authored and Ben Gamari's avatar Ben Gamari committed
      This for some reason or the other and makes it into the final
      binary. I've added the check to ContFlowOpt as that seems
      like a logical place for this.
      
      In a regular nofib run there were 30 occurences of this pattern.
      
      Test Plan: ci
      
      Reviewers: bgamari, simonmar, dfeuer, jrtc27, tdammers
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: tdammers, dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #15188
      
      Differential Revision: https://phabricator.haskell.org/D4740
      efea32cf
    • Andreas Herrmann's avatar
      Fix unparseable pretty-printing of promoted data cons · 767536cc
      Andreas Herrmann authored and Ben Gamari's avatar Ben Gamari committed
      Previously we would print code which would not round-trip:
      ```
      > :set -XDataKinds
      > :set -XPolyKinds
      > data Proxy k = Proxy
      > _ :: Proxy '[ 'True ]
      error:
        Found hole: _ :: Proxy '['True]
      > _ :: Proxy '['True]
      error:
          Invalid type signature: _ :: ...
          Should be of form <variable> :: <type>
      ```
      
      Test Plan: Validate with T14343
      
      Reviewers: RyanGlScott, goldfire, bgamari, tdammers
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      GHC Trac Issues: #14343
      
      Differential Revision: https://phabricator.haskell.org/D4746
      767536cc
    • David Feuer's avatar
      Index arrays more eagerly · e7678d6a
      David Feuer authored and Ben Gamari's avatar Ben Gamari committed
      Many basic functions in `GHC.Arr` were unreasonably lazy about
      performing array lookups. This could lead to useless thunks
      at best and memory leaks at worst. Use eager lookups where
      they're obviously appropriate.
      
      Reviewers: bgamari, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4773
      e7678d6a
    • Ben Gamari's avatar
      WorkWrap: Rip out unsafeGlobalDynFlags usage in mkWwInlineRule · db4f064e
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4775
      db4f064e
    • Ben Gamari's avatar
      Don't use unsafeGlobalDynFlags in optCoercion · 64c71ce9
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      This plumbs DynFlags through CoreOpt so optCoercion can finally
      eliminate its usage of `unsafeGlobalDynFlags`.
      
      Note that this doesn't completely eliminate `unsafeGlobalDynFlags`
      usage from this bit of the compiler. A few uses are introduced in
      call-sites where we don't (yet) have ready access to `DynFlags`.
      
      Test Plan: Validate
      
      Reviewers: goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4774
      64c71ce9
    • Ben Gamari's avatar
      Update hadrian submodule · f7417118
      Ben Gamari authored
      f7417118
    • Ben Gamari's avatar
      testsuite: Fix dynamic-paper stderr file · 1508600c
      Ben Gamari authored
      The stderr file was empty, yet GHC fails with an error.
      1508600c
    • Simon Peyton Jones's avatar
      Remove ad-hoc special case in occAnal · c16382d5
      Simon Peyton Jones authored
      Back in 1999 I put this ad-hoc code in the Case-handling
      code for occAnal:
      
        occAnal env (Case scrut bndr ty alts)
         = ...
              -- Note [Case binder usage]
              -- ~~~~~~~~~~~~~~~~~~~~~~~~
              -- The case binder gets a usage of either "many" or "dead", never "one".
              -- Reason: we like to inline single occurrences, to eliminate a binding,
              -- but inlining a case binder *doesn't* eliminate a binding.
              -- We *don't* want to transform
              --      case x of w { (p,q) -> f w }
              -- into
              --      case x of w { (p,q) -> f (p,q) }
          tag_case_bndr usage bndr
            = (usage', setIdOccInfo bndr final_occ_info)
            where
              occ_info       = lookupDetails usage bndr
              usage'         = usage `delDetails` bndr
              final_occ_info = case occ_info of IAmDead -> IAmDead
                                                _       -> noOccInfo
      
      But the comment looks wrong -- the bad inlining will not happen -- and
      I think it relates to some long-ago version of the simplifier.
      
      So I simply removed the special case, which gives more accurate
      occurrence-info to the case binder.  Interestingly I got a slight
      improvement in nofib binary sizes.
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
            cacheprof          -0.1%     +0.2%     -0.7%     -1.2%     +8.6%
      --------------------------------------------------------------------------------
                  Min          -0.2%      0.0%    -14.5%    -30.5%      0.0%
                  Max          -0.1%     +0.2%    +10.0%    +10.0%    +25.0%
       Geometric Mean          -0.2%     +0.0%     -1.9%     -5.4%     +0.3%
      
      I have no idea if the improvement in runtime is real.  I did look at the
      tiny increase in allocation for cacheprof and concluded that it was
      unimportant (I forget the details).
      
      Also the more accurate occ-info for the case binder meant that some
      inlining happens in one pass that previously took successive passes
      for the test dependent/should_compile/dynamic-paper (which has a
      known Russel-paradox infinite loop in the simplifier).
      
      In short, a small win: less ad-hoc complexity and slightly smaller
      binaries.
      c16382d5
    • Simon Peyton Jones's avatar
      Comments only · 7f459064
      Simon Peyton Jones authored
      7f459064
    • Ömer Sinan Ağacan's avatar
      Do not scavenge SMALL_MUT_ARR_PTRS_CLEAN in mut_lists · 635a59a5
      Ömer Sinan Ağacan authored
      For the same reason with MUT_ARR_PTRS_CLEAN we don't need to scavenge
      SMALL_MUT_ARR_PTRS_CLEAN in mut_lists.
      
      Because SMALL_MUT_ARR_PTRS doesn't have a card table we don't have a
      special case when scavenging SMALL_MUT_ARR_PTRS_DIRTY in a mut_list.
      
      Test Plan: this validates
      
      Reviewers: simonmar, bgamari, erikd
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4800
      635a59a5
  5. 06 Jun, 2018 1 commit
  6. 05 Jun, 2018 3 commits
    • Ömer Sinan Ağacan's avatar
      rts: Reuse dbl_link_remove in a few places · 455477a3
      Ömer Sinan Ağacan authored
      Test Plan: this validates
      
      Reviewers: simonmar, bgamari, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4795
      455477a3
    • Ömer Sinan Ağacan's avatar
      Rename some mutable closure types for consistency · 4075656e
      Ömer Sinan Ağacan authored
      SMALL_MUT_ARR_PTRS_FROZEN0 -> SMALL_MUT_ARR_PTRS_FROZEN_DIRTY
      SMALL_MUT_ARR_PTRS_FROZEN  -> SMALL_MUT_ARR_PTRS_FROZEN_CLEAN
      MUT_ARR_PTRS_FROZEN0       -> MUT_ARR_PTRS_FROZEN_DIRTY
      MUT_ARR_PTRS_FROZEN        -> MUT_ARR_PTRS_FROZEN_CLEAN
      
      Naming is now consistent with other CLEAR/DIRTY objects (MVAR, MUT_VAR,
      MUT_ARR_PTRS).
      
      (alternatively we could rename MVAR_DIRTY/MVAR_CLEAN etc. to MVAR0/MVAR)
      
      Removed a few comments in Scav.c about FROZEN0 being on the mut_list
      because it's now clear from the closure type.
      
      Reviewers: bgamari, simonmar, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4784
      4075656e
    • Ryan Scott's avatar
      Introduce DerivingVia · 8ed8b037
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      This implements the `DerivingVia` proposal put forth in
      https://github.com/ghc-proposals/ghc-proposals/pull/120.
      
      This introduces the `DerivingVia` deriving strategy. This is a
      generalization of `GeneralizedNewtypeDeriving` that permits the user
      to specify the type to `coerce` from.
      
      The major change in this patch is the introduction of the
      `ViaStrategy` constructor to `DerivStrategy`, which takes a type
      as a field. As a result, `DerivStrategy` is no longer a simple
      enumeration type, but rather something that must be renamed and
      typechecked. The process by which this is done is explained more
      thoroughly in section 3 of this paper
      ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ),
      although I have inlined the relevant parts into Notes where possible.
      
      There are some knock-on changes as well. I took the opportunity to
      do some refactoring of code in `TcDeriv`, especially the
      `mkNewTypeEqn` function, since it was bundling all of the logic for
      (1) deriving instances for newtypes and
      (2) `GeneralizedNewtypeDeriving`
      into one huge broth. `DerivingVia` reuses much of part (2), so that
      was factored out as much as possible.
      
      Bumps the Haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, goldfire, alanz
      
      Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15178
      
      Differential Revision: https://phabricator.haskell.org/D4684
      8ed8b037
  7. 04 Jun, 2018 4 commits