1. 09 Oct, 2019 1 commit
  2. 08 Oct, 2019 1 commit
  3. 07 Oct, 2019 2 commits
  4. 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
  5. 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
  6. 20 Sep, 2019 1 commit
  7. 17 Sep, 2019 1 commit
  8. 13 Sep, 2019 1 commit
  9. 12 Sep, 2019 1 commit
  10. 09 Sep, 2019 1 commit
    • Sylvain Henry's avatar
      Module hierarchy: StgToCmm (#13009) · 447864a9
      Sylvain Henry authored
      Add StgToCmm module hierarchy. Platform modules that are used in several
      other places (NCG, LLVM codegen, Cmm transformations) are put into
      GHC.Platform.
      447864a9
  11. 07 Sep, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Minor refactoring in deriveConstants · 821bece9
      Ömer Sinan Ağacan authored
      Mainly we now generate this
      
          data PlatformConstants = PlatformConstants {
                pc_CONTROL_GROUP_CONST_291 :: Int,
                pc_STD_HDR_SIZE :: Int,
                pc_PROF_HDR_SIZE :: Int,
                pc_BLOCK_SIZE :: Int,
            }
      
      instead of
      
          data PlatformConstants = PlatformConstants {
              pc_platformConstants :: ()
              , pc_CONTROL_GROUP_CONST_291 :: Int
              , pc_STD_HDR_SIZE :: Int
              , pc_PROF_HDR_SIZE :: Int
              , pc_BLOCK_SIZE :: Int
              ...
            }
      
      The first field has no use and according to (removed) comments it was to
      make code generator's work easier.. if anything this version is simpler
      because it has less repetition (the commas in strings are gone).
      821bece9
  12. 07 Aug, 2019 1 commit
  13. 21 Jul, 2019 1 commit
  14. 14 Jul, 2019 1 commit
    • John Ericson's avatar
      Expunge #ifdef and #ifndef from the codebase · d7c6c471
      John Ericson authored
      These are unexploded minds as far as the linter is concerned. I don't
      want to hit in my MRs by mistake!
      
      I did this with `sed`, and then rolled back some changes in the docs,
      config.guess, and the linter itself.
      d7c6c471
  15. 10 Jul, 2019 2 commits
    • John Ericson's avatar
      Deduplicate "unique subdir" code between GHC and Cabal · 24782b89
      John Ericson authored
      The code, including the generated module with the version, is now in
      ghc-boot. Config.hs reexports stuff as needed, ghc-pkg doesn't need any
      tricks at all.
      24782b89
    • John Ericson's avatar
      Remove most uses of TARGET platform macros · 0472f0f6
      John Ericson authored
      These prevent multi-target builds. They were gotten rid of in 3 ways:
      
      1. In the compiler itself, replacing `#if` with runtime `if`. In these
      cases, we care about the target platform still, but the target platform
      is dynamic so we must delay the elimination to run time.
      
      2. In the compiler itself, replacing `TARGET` with `HOST`. There was
      just one bit of this, in some code splitting strings representing lists
      of paths. These paths are used by GHC itself, and not by the compiled
      binary. (They are compiler lookup paths, rather than RPATHS or something
      that does matter to the compiled binary, and thus would legitamentally
      be target-sensative.) As such, the path-splitting method only depends on
      where GHC runs and not where code it produces runs. This should have
      been `HOST` all along.
      
      3. Changing the RTS. The RTS doesn't care about the target platform,
      full stop.
      
      4. `includes/stg/HaskellMachRegs.h` This file is also included in the
      genapply executable. This is tricky because the RTS's host platform
      really is that utility's target platform. so that utility really really
      isn't multi-target either. But at least it isn't an installed part of
      GHC, but just a one-off tool when building the RTS. Lying with the
      `HOST` to a one-off program (genapply) that isn't installed doesn't seem so bad.
      It's certainly better than the other way around of lying to the RTS
      though not to genapply. The RTS is more important, and it is installed,
      *and* this header is installed as part of the RTS.
      0472f0f6
  16. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  17. 26 Jun, 2019 2 commits
    • Oleg Grenrus's avatar
      Add -Winferred-safe-imports warning · a863c44f
      Oleg Grenrus authored
      This commit partly reverts e69619e9
      commit by reintroducing Sf_SafeInferred SafeHaskellMode.
      
      We preserve whether module was declared or inferred Safe.  When
      declared-Safe module imports inferred-Safe, we warn.  This inferred
      status is volatile, often enough it's a happy coincidence, something
      which cannot be relied upon. However, explicitly Safe or Trustworthy
      packages won't accidentally become Unsafe.
      
      Updates haddock submodule.
      a863c44f
    • Ben Gamari's avatar
      Bump containers submodule to v0.6.2.1 · 4c2127c4
      Ben Gamari authored
      4c2127c4
  18. 24 Jun, 2019 1 commit
  19. 20 Jun, 2019 1 commit
  20. 16 Jun, 2019 2 commits
  21. 13 Jun, 2019 1 commit
  22. 12 Jun, 2019 2 commits
  23. 11 Jun, 2019 1 commit
    • Alp Mestanogullari's avatar
      Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETER · 39f50bff
      Alp Mestanogullari authored
      As discussed in #16331, the GHCI macro, defined through 'ghci' flags
      in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
      whether GHC is built with support for an internal interpreter, that runs in
      the same process. It is however overloaded in a few places to mean
      "there is an interpreter available", regardless of whether it's an internal
      or external interpreter.
      
      For the sake of clarity and with the hope of more easily being able to
      build stage 1 GHCs with external interpreter support, this patch splits
      the previous GHCI macro into 3 different ones:
      
      - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
      - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
      - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
      39f50bff
  24. 07 Jun, 2019 2 commits
    • Moritz Angermann's avatar
      llvm-targets: Add x86_64 android layout · e87b9f87
      Moritz Angermann authored
      e87b9f87
    • John Ericson's avatar
      Factor out 'getLibDir' / 'getBaseDir' into a new GHC.BaseDir ghc-boot module · 387050d0
      John Ericson authored
      ghc-pkg and ghc already both needed this. I figure it is better to
      deduplicate, especially seeing that changes to one (FreeBSD CPP) didn't
      make it to the other.
      
      Additionally in !1090 I make ghc-pkg look up the settings file, which
      makes it use the top dir a bit more widely. If that lands, any
      difference in the way they find the top dir would be more noticable.
      
      That change also means sharing more code between ghc and ghc-package
      (namely the settings file parsing code), so I'd think it better to get
      off the slipperly slope of duplicating code now.
      387050d0
  25. 31 May, 2019 2 commits
  26. 29 May, 2019 1 commit
    • John Ericson's avatar
      Inline `Settings` into `DynFlags` · bfccd832
      John Ericson authored
      After the previous commit, `Settings` is just a thin wrapper around
      other groups of settings. While `Settings` is used by GHC-the-executable
      to initalize `DynFlags`, in principle another consumer of
      GHC-the-library could initialize `DynFlags` a different way. It
      therefore doesn't make sense for `DynFlags` itself (library code) to
      separate the settings that typically come from `Settings` from the
      settings that typically don't.
      bfccd832
  27. 24 May, 2019 1 commit
    • Ryan Scott's avatar
      Some forall-related cleanup in deriving code · 6eedbd83
      Ryan Scott authored
      * Tweak the parser to allow `deriving` clauses to mention explicit
        `forall`s or kind signatures without gratuitous parentheses.
        (This fixes #14332 as a consequence.)
      * Allow Haddock comments on `deriving` clauses with explicit
        `forall`s. This requires corresponding changes in Haddock.
      6eedbd83
  28. 22 May, 2019 1 commit
    • Ryan Scott's avatar
      Use HsTyPats in associated type family defaults · 6efe04de
      Ryan Scott authored
      Associated type family default declarations behave strangely in a
      couple of ways:
      
      1. If one tries to bind the type variables with an explicit `forall`,
         the `forall`'d part will simply be ignored. (#16110)
      2. One cannot use visible kind application syntax on the left-hand
         sides of associated default equations, unlike every other form
         of type family equation. (#16356)
      
      Both of these issues have a common solution. Instead of using
      `LHsQTyVars` to represent the left-hand side arguments of an
      associated default equation, we instead use `HsTyPats`, which is what
      other forms of type family equations use. In particular, here are
      some highlights of this patch:
      
      * `FamEqn` is no longer parameterized by a `pats` type variable, as
        the `feqn_pats` field is now always `HsTyPats`.
      * The new design for `FamEqn` in chronicled in
        `Note [Type family instance declarations in HsSyn]`.
      * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
        means that many of `TyFamDefltEqn`'s code paths can now reuse the
        code paths for `TyFamInstEqn`, resulting in substantial
        simplifications to various parts of the code dealing with
        associated type family defaults.
      
      Fixes #16110 and #16356.
      6efe04de
  29. 25 Apr, 2019 1 commit
  30. 01 Apr, 2019 1 commit
    • Takenobu Tani's avatar
      Clean up URLs to point to GitLab · 27b99ed8
      Takenobu Tani authored
      This moves URL references to old Trac to their corresponding
      GitLab counterparts.
      
      This patch does not update the submodule library, such as
      libraries/Cabal.
      
      See also !539, !606, !618
      
      [ci skip]
      27b99ed8
  31. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      This moves all URL references to Trac Wiki to their corresponding
      GitLab counterparts.
      
      This substitution is classified as follows:
      
      1. Automated substitution using sed with Ben's mapping rule [1]
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
      
      2. Manual substitution for URLs containing `#` index
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
      
      3. Manual substitution for strings starting with `Commentary`
          Old: Commentary/XxxYyy...
          New: commentary/xxx-yyy...
      
      See also !539
      
      [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
      3769e3a8