Skip to content
Snippets Groups Projects
  1. Jul 24, 2017
  2. Jul 23, 2017
  3. Jul 22, 2017
  4. Jul 21, 2017
    • Ben Gamari's avatar
      build system: Ensure there are no duplicate files in bindist list · fefcbfa8
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Several executables inexplicably appear twice in bindist.list, which
      ends up producing multiple tar file entries, consequently breaking BSD
      tar during extraction. I spent a fair amount of time trying to work out
      where these duplicates were coming from to no avail. Since Hadrian is
      right around the corner I'm satisfied with a terrible hack: just uniq
      bindist.list before producing the bindist tarball.
      
      Test Plan: Validate
      
      Reviewers: austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13979, #13974
      
      Differential Revision: https://phabricator.haskell.org/D3767
      fefcbfa8
  5. Jul 20, 2017
  6. Jul 19, 2017
    • Andrew Martin's avatar
      base: Improve docs to clarify when finalizers may not be run · b066d936
      Andrew Martin authored and Ben Gamari's avatar Ben Gamari committed
      b066d936
    • Chris Martin's avatar
      typo: -XUndeci[d]ableInstances · 927e7810
      Chris Martin authored and Ben Gamari's avatar Ben Gamari committed
      927e7810
    • Ryan Scott's avatar
      Fix #13983 by creating a TyConFlavour type, and using it · 6e3c901d
      Ryan Scott authored
      An error message was referring to a type synonym as a datatype.
      Annoyingly, learning that the TyCon over which the error message is
      operating is actually a type synonym was previously impossible, since
      that code only had access to a TcTyCon, which doesn't retain any
      information about what sort of TyCon it is.
      
      To rectify this, I created a new TyConFlavour datatype, intended to
      capture roughly what sort of TyCon we're dealing with. I then performing
      the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and
      propagated this information through to the relevant error message.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13983
      
      Differential Revision: https://phabricator.haskell.org/D3747
      6e3c901d
    • Ben Gamari's avatar
      dmdAnal: Ensure that ExnStr flag isn't dropped inappropriately · c940e3b9
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      This fixes #13977 and consequently #13615. Here an optimization in the
      demand analyser was too liberal, causing us to drop the ExnStr flag and
      consequently resulting in incorrect demand signatures. This manifested
      as a segmentation fault in #13615 as we incorrectly concluded that an
      application of catchRetry# would bottom.
      
      Specifically, we had
      
          orElse' :: STM a -> STM a -> STM a
          orElse' x = catchRetry# x y
            where y = {- some action -}
      
      Where the catchRetry# primop places a demand of <xC(S),1*C1(U)> on its
      first argument. However, due to #13977 the demand analyser would assign
      a demand of <C(S),1*C1(U)> on the first argument of orElse'. Note the
      missing `x`.
      
          case orElse' bottomingAction anotherAction of { x -> Just x }
      
      being transformed to,
      
          case orElse' bottomingAction anotherAction of {}
      
      by the simplifier. This would naturally blow up when orElse' returned at
      runtime, causing the segmentation fault described in #13615.
      
      Test Plan: Validate, perhaps add a testcase
      
      Reviewers: austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13977, #13615
      
      Differential Revision: https://phabricator.haskell.org/D3756
      c940e3b9
Loading