1. 25 Jan, 2020 1 commit
    • Ryan Scott's avatar
      Handle local fixity declarations in DsMeta properly · c3fde723
      Ryan Scott authored
      `DsMeta.rep_sig` used to skip over `FixSig` entirely, which had the
      effect of causing local fixity declarations to be dropped when quoted
      in Template Haskell. But there is no good reason for this state of
      affairs, as the code in `DsMeta.repFixD` (which handles top-level
      fixity declarations) handles local fixity declarations just fine.
      This patch factors out the necessary parts of `repFixD` so that they
      can be used in `rep_sig` as well.
      
      There was one minor complication: the fixity signatures for class
      methods in each `HsGroup` were stored both in `FixSig`s _and_ the
      list of `LFixitySig`s for top-level fixity signatures, so I needed
      to take action to prevent fixity signatures for class methods being
      converted to `Dec`s twice. I tweaked `RnSource.add` to avoid putting
      these fixity signatures in two places and added
      `Note [Top-level fixity signatures in an HsGroup]` in `GHC.Hs.Decls`
      to explain the new design.
      
      Fixes #17608. Bumps the Haddock submodule.
      c3fde723
  2. 13 Jan, 2020 1 commit
  3. 08 Jan, 2020 1 commit
  4. 06 Jan, 2020 1 commit
  5. 04 Jan, 2020 2 commits
  6. 12 Dec, 2019 1 commit
  7. 03 Dec, 2019 1 commit
    • Ben Gamari's avatar
      Make BCO# lifted · 705a16df
      Ben Gamari authored
      In #17424 Simon PJ noted that there is a potentially unsafe occurrence
      of unsafeCoerce#, coercing from an unlifted to lifted type. However,
      nowhere in the compiler do we assume that a BCO# is not a thunk.
      Moreover, in the case of a CAF the result returned by `createBCO` *will*
      be a thunk (as noted in [Updatable CAF BCOs]).  Consequently it seems
      better to rather make BCO# a lifted type and rename it to BCO.
      705a16df
  8. 02 Dec, 2019 1 commit
  9. 30 Nov, 2019 1 commit
  10. 28 Nov, 2019 1 commit
  11. 27 Nov, 2019 1 commit
    • Vladislav Zavialov's avatar
      Whitespace-sensitive bang patterns (#1087, #17162) · 8168b42a
      Vladislav Zavialov authored
      This patch implements a part of GHC Proposal #229 that covers five
      operators:
      
      * the bang operator (!)
      * the tilde operator (~)
      * the at operator (@)
      * the dollar operator ($)
      * the double dollar operator ($$)
      
      Based on surrounding whitespace, these operators are disambiguated into
      bang patterns, lazy patterns, strictness annotations, type
      applications, splices, and typed splices.
      
      This patch doesn't cover the (-) operator or the -Woperator-whitespace
      warning, which are left as future work.
      8168b42a
  12. 24 Nov, 2019 1 commit
  13. 23 Nov, 2019 2 commits
  14. 21 Nov, 2019 1 commit
  15. 20 Nov, 2019 1 commit
    • Alexey Kuleshevich's avatar
      hpc: Fix encoding issues. Add test for and fix #17073 · ef8a08e0
      Alexey Kuleshevich authored
      * Make sure files are being read/written in UTF-8. Set encoding while writing
        HTML output. Also set encoding while writing and reading .tix files although
        we don't yet have a ticket complaining that this poses problems.
      * Set encoding in html header to utf8
      * Upgrade to new version of 'hpc' library and reuse `readFileUtf8`
        and `writeFileUtf8` functions
      * Update git submodule for `hpc`
      * Bump up `hpc` executable version
      Co-authored-by: Ben Gamari's avatarBen Gamari <ben@smart-cactus.org>
      ef8a08e0
  16. 17 Nov, 2019 1 commit
  17. 14 Nov, 2019 1 commit
  18. 13 Nov, 2019 1 commit
    • Ben Gamari's avatar
      Ensure that coreView/tcView are able to inline · 2d4f9ad8
      Ben Gamari authored
      Previously an import cycle between Type and TyCoRep meant that several
      functions in TyCoRep ended up SOURCE import coreView. This is quite
      unfortunate as coreView is intended to be fused into a larger pattern
      match and not incur an extra call.
      
      Fix this with a bit of restructuring:
      
       * Move the functions in `TyCoRep` which depend upon things in `Type`
         into `Type`
       * Fold contents of `Kind` into `Type` and turn `Kind` into a simple
         wrapper re-exporting kind-ish things from `Type`
       * Clean up the redundant imports that popped up as a result
      
      Closes #17441.
      
      Metric Decrease:
          T4334
      2d4f9ad8
  19. 08 Nov, 2019 1 commit
  20. 06 Nov, 2019 1 commit
    • Takenobu Tani's avatar
      configure: Add checking python3-sphinx · 97f9674b
      Takenobu Tani authored
      This checks the configuration about python3-sphinx.
      We need python3-sphinx instead of python2-sphinx to build documentation.
      
      The approach is as follows:
      * Check python3 version with custom `conf.py` invoked from
        sphinx-build` executable
      * Place custom `conf.py` into new `utils/check-sphinx` directory
      
      If sphinx is for python2 not python3, it's treated as config ERROR
      instead of WARN.
      
      See also #17346 and #17356.
      97f9674b
  21. 03 Nov, 2019 1 commit
    • Sebastian Graf's avatar
      Separate `LPat` from `Pat` on the type-level · 182b1199
      Sebastian Graf authored
      Since the Trees That Grow effort started, we had `type LPat = Pat`.
      This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
      the reason why all GHC passes use the extension constructor `XPat` to
      attach source locations. See #15495 for the design discussion behind
      that.
      
      But now suddenly there are `XPat`s everywhere!
      There are several functions which dont't cope with `XPat`s by either
      crashing (`hsPatType`) or simply returning incorrect results
      (`collectEvVarsPat`).
      
      This issue was raised in #17330. I also came up with a rather clean and
      type-safe solution to the problem: We define
      
      ```haskell
      type family XRec p (f :: * -> *) = r | r -> p f
      type instance XRec (GhcPass p) f = Located (f (GhcPass p))
      type instance XRec TH          f =          f p
      type LPat p = XRec p Pat
      ```
      
      This is a rather modular embedding of the old "ping-pong" style, while
      we only pay for the `Located` wrapper within GHC. No ping-ponging in
      a potential Template Haskell AST, for example. Yet, we miss no case
      where we should've handled a `SrcLoc`: `hsPatType` and
      `collectEvVarsPat` are not callable at an `LPat`.
      
      Also, this gets rid of one indirection in `Located` variants:
      Previously, we'd have to go through `XPat` and `Located` to get from
      `LPat` to the wrapped `Pat`. Now it's just `Located` again.
      
      Thus we fix #17330.
      182b1199
  22. 29 Oct, 2019 1 commit
  23. 28 Oct, 2019 1 commit
    • Sebastian Graf's avatar
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances... · e951f219
      Sebastian Graf authored
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances with equality constraints
      
      In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
      for `Outputable` instances of AST data types means users can provide orphan
      `Outputable` instances for passes other than `GhcPass`.
      
      Type inference doesn't currently to suffer, and Richard gave an example
      in #17304 that shows how rare a case would be where the slightly worse
      type inference would matter.
      
      So I went ahead with the refactoring, attempting to fix #17304.
      e951f219
  24. 23 Oct, 2019 1 commit
    • Andreas Klebinger's avatar
      Make dynflag argument for withTiming pure. · 6beea836
      Andreas Klebinger authored
      19 times out of 20 we already have dynflags in scope.
      
      We could just always use `return dflags`. But this is in fact not free.
      When looking at some STG code I noticed that we always allocate a
      closure for this expression in the heap. Clearly a waste in these cases.
      
      For the other cases we can either just modify the callsite to
      get dynflags or use the _D variants of withTiming I added which
      will use getDynFlags under the hood.
      6beea836
  25. 22 Oct, 2019 2 commits
    • Stefan Schulze Frielinghaus's avatar
      Implement s390x LLVM backend. · fd8b666a
      Stefan Schulze Frielinghaus authored
      This patch adds support for the s390x architecture for the LLVM code
      generator. The patch includes a register mapping of STG registers onto
      s390x machine registers which enables a registerised build.
      fd8b666a
    • matthewbauer's avatar
      Replace freebsd-gnueabihf with freebsd · aa31ceaf
      matthewbauer authored
      FreeBSD does not support GNU libc, so it makes no sense to use this
      triple. Most likely previous builds were just using the FreeBSD libc
      instead of gnueabihf. To fix this, we should just use
      armv6-unknown-freebsd and armv7-unknown-freebsd triples. Note that
      both of these are actually "soft-float", not "hard-float". FreeBSD has
      never officially released hard-float arm32:
      
      https://wiki.freebsd.org/ARMTier1
      aa31ceaf
  26. 20 Oct, 2019 1 commit
  27. 18 Oct, 2019 1 commit
  28. 16 Oct, 2019 1 commit
  29. 09 Oct, 2019 1 commit
  30. 08 Oct, 2019 1 commit
  31. 07 Oct, 2019 2 commits
  32. 05 Oct, 2019 3 commits
    • matthewbauer's avatar
      Add musl systems to llvm-targets · 8039b625
      matthewbauer authored
      This was done in Nixpkgs, but never upstreamed. Musl is pretty much
      the same as gnu, but with a different libc. I’ve used the same values
      for everything.
      8039b625
    • John Ericson's avatar
      dd8f76b2
    • John Ericson's avatar
      Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.h · 05419e55
      John Ericson authored
      The generated headers are now generated per stage, which means we can
      skip hacks like `ghc_boot_platform.h` and just have that be the stage 0
      header as proper. In general, stages are to be embraced: freely generate
      everything in each stage but then just build what you depend on, and
      everything is symmetrical and efficient. Trying to avoid stages because
      bootstrapping is a mind bender just creates tons of bespoke
      mini-mind-benders that add up to something far crazier.
      
      Hadrian was pretty close to this "stage-major" approach already, and so
      was fairly easy to fix. Make needed more work, however: it did know
      about stages so at least there was a scaffold, but few packages except
      for the compiler cared, and the compiler used its own counting system.
      That said, make and Hadrian now work more similarly, which is good for
      the transition to Hadrian. The merits of embracing stage aside, the
      change may be worthy for easing that transition alone.
      05419e55
  33. 25 Sep, 2019 1 commit
    • Ryan Scott's avatar
      Remove unneeded CPP now that GHC 8.6 is the minimum · 795986aa
      Ryan Scott authored
      The minimum required GHC version for bootstrapping is 8.6, so we can
      get rid of some unneeded `#if `__GLASGOW_HASKELL__` CPP guards, as
      well as one `MIN_VERSION_ghc_prim(0,5,3)` guard (since GHC 8.6 bundles
      `ghc-prim-0.5.3`).
      795986aa
  34. 20 Sep, 2019 1 commit