1. 12 Jun, 2019 1 commit
  2. 11 Jun, 2019 2 commits
    • 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
    • Yuras's avatar
      Warn about unused packages · fe7e7e4a
      Yuras authored
      Reviewers: bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: hvr, simonpj, mpickering, rwbarton, carter
      GHC Trac Issues: #15838
      Differential Revision: https://phabricator.haskell.org/D5285
  3. 09 Jun, 2019 1 commit
    • KevinBuhr's avatar
      Handle trailing path separator in package DB names (#16360) · 9d238791
      KevinBuhr authored
      Package DB directories with trailing separator (provided via
      GHC_PACKAGE_PATH or via -package-db) resulted in incorrect calculation of
      ${pkgroot} substitution variable.  Keep the trailing separator while
      resolving as directory or file, but remove it before dropping the last
      path component with takeDirectory.
      Closes #16360.
  4. 08 Jun, 2019 1 commit
  5. 07 Jun, 2019 2 commits
  6. 04 Jun, 2019 1 commit
    • xldenis's avatar
      Add GHCi :instances command · 002594b7
      xldenis authored
      This commit adds the `:instances` command to ghci following proosal
      number 41.
      This makes it possible to query which instances are available to a given
      The output of this command is all the possible instances with type
      variables and constraints instantiated.
  7. 31 May, 2019 3 commits
  8. 30 May, 2019 8 commits
    • Daniel Gröber (dxld)'s avatar
      Improve targetContents code docs · d2784771
      Daniel Gröber (dxld) authored
    • Daniel Gröber (dxld)'s avatar
      Add depanalPartial to make getting a partial modgraph easier · 98e39818
      Daniel Gröber (dxld) authored
      As per @mpickering's suggestion on IRC this is to make the partial
      module-graph more easily accessible for API clients which don't intend to
      re-implementing depanal.
    • Daniel Gröber (dxld)'s avatar
      Catch preprocessor errors in downsweep · 99e72769
      Daniel Gröber (dxld) authored
      This changes the way preprocessor failures are presented to the
      user. Previously the user would simply get an unlocated message on stderr
      such as:
          `gcc' failed in phase `C pre-processor'. (Exit code: 1)
      Now at the problematic source file is mentioned:
          A.hs:1:1: error:
              `gcc' failed in phase `C pre-processor'. (Exit code: 1)
      This also makes live easier for GHC API clients as the preprocessor error
      is now thrown as a SourceError exception.
    • Daniel Gröber (dxld)'s avatar
      Make downsweep return all errors per-module instead of throwing some · 18d3f01d
      Daniel Gröber (dxld) authored
      This enables API clients to handle such errors instead of immideately
      crashing in the face of some kinds of user errors, which is arguably quite
      bad UX.
      Fixes #10887
    • Daniel Gröber (dxld)'s avatar
      Refactor summarise{File,Module} to extract checkSummaryTimestamp · 76c86fca
      Daniel Gröber (dxld) authored
      This introduces a slight change of behaviour in the interrest of keeping
      the code simple: Previously summariseModule would not call
      addHomeModuleToFinder for summaries that are being re-used but now we do.
      We're forced to to do this in summariseFile because the file being
      summarised might not even be on the regular search path! So if GHC is to
      find it at all we have to pre-populate the cache with its location. For
      modules however the finder cache is really just a cache so we don't have to
      pre-populate it with the module's location.
      As straightforward as that seems I did almost manage to introduce a bug (or
      so I thought) because the call to addHomeModuleToFinder I copied from
      summariseFile used to use `ms_location old_summary` instead of the
      `location` argument to checkSummaryTimestamp. If this call were to
      overwrite the existing entry in the cache that would have resulted in us
      using the old location of any module even if it was, say, moved to a
      different directory between calls to 'depanal'.
      However it turns out the cache just ignores the location if the module is
      already in the cache. Since summariseModule has to search for the module,
      which has the side effect of populating the cache, everything would have
      been fine either way.
      Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.
    • Daniel Gröber (dxld)'s avatar
    • Daniel Gröber (dxld)'s avatar
    • Daniel Gröber (dxld)'s avatar
      Export GhcMake.downsweep · 70afa539
      Daniel Gröber (dxld) authored
      This is to enable #10887 as well as to make it possible to test downsweep
      on its own in the testsuite.
  9. 29 May, 2019 5 commits
    • 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.
    • John Ericson's avatar
      Break up `Settings` into smaller structs · ace2e335
      John Ericson authored
      As far as I can tell, the fields within `Settings` aren't *intrinsicly*
      related. They just happen to be initialized the same way (in particular
      prior to the rest of `DynFlags`), and that is why they are grouped
      Within `Settings`, however, there are groups of settings that clearly do
      share something in common, regardless of how they anything is
      In the spirit of GHC being a library, where the end cosumer may choose
      to initialize this configuration in arbitrary ways, I made some new data
      types for thoses groups internal to `Settings`, and used them to define
      `Settings` instead. Hopefully this is a baby step towards a general
      decoupling of the stateful and stateless parts of GHC.
    • Daniel Gröber (dxld)'s avatar
      downsweep: Allow TargetFile not to exist when a buffer is given · fb26d467
      Daniel Gröber (dxld) authored
      Currently 'getRootSummary' will fail with an exception if a 'TargetFile' is
      given but it does not exist even if an input buffer is passed along for
      this target.
      In this case it is not necessary for the file to exist since the buffer
      will be used as input for the compilation pipeline instead of the file
    • Daniel Gröber (dxld)'s avatar
      Allow using tagetContents for modules needing preprocessing · 5b90e0a1
      Daniel Gröber (dxld) authored
      This allows GHC API clients, most notably tooling such as
      Haskell-IDE-Engine, to pass unsaved files to GHC more easily.
      Currently when targetContents is used but the module requires preprocessing
      'preprocessFile' simply throws an error because the pipeline does not
      support passing a buffer.
      This change extends `runPipeline` to allow passing the input buffer into
      the pipeline. Before proceeding with the actual pipeline loop the input
      buffer is immediately written out to a new tempfile.
      I briefly considered refactoring the pipeline at large to pass around
      in-memory buffers instead of files, but this seems needlessly complicated
      since no pipeline stages other than Hsc could really support this at the
    • Krzysztof Gogolewski's avatar
  10. 22 May, 2019 2 commits
  11. 21 May, 2019 1 commit
  12. 14 May, 2019 2 commits
    • Vladislav Zavialov's avatar
      Guard CUSKs behind a language pragma · a5fdd185
      Vladislav Zavialov authored
      GHC Proposal #36 describes a transition plan away from CUSKs and to
      top-level kind signatures:
      1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs
         as they currently exist.
      2. We turn off the -XCUSKs extension in a few releases and remove it
         sometime thereafter.
      This patch implements phase 1 of this plan, introducing a new language
      extension to control whether CUSKs are enabled. When top-level kind
      signatures are implemented, we can transition to phase 2.
    • John Ericson's avatar
      Remove all target-specific portions of Config.hs · e529c65e
      John Ericson authored
      1. If GHC is to be multi-target, these cannot be baked in at compile
      2. Compile-time flags have a higher maintenance than run-time flags.
      3. The old way makes build system implementation (various bootstrapping
         details) with the thing being built. E.g. GHC doesn't need to care
         about which integer library *will* be used---this is purely a crutch
         so the build system doesn't need to pass flags later when using that
      4. Experience with cross compilation in Nixpkgs has shown things work
         nicer when compiler's can *optionally* delegate the bootstrapping the
         package manager. The package manager knows the entire end-goal build
         plan, and thus can make top-down decisions on bootstrapping. GHC can
         just worry about GHC, not even core library like base and ghc-prim!
  13. 08 May, 2019 2 commits
  14. 06 May, 2019 2 commits
  15. 01 May, 2019 3 commits
  16. 16 Apr, 2019 1 commit
    • Dmitry Dolgov's avatar
      Show dynamic object files (#16062) · 57eb5bc6
      Dmitry Dolgov authored
      Closes #16062. When -dynamic-too is specified, reflect that in the
      progress message, like:
      $ ghc Main.hs -dynamic-too
      [1 of 1] Compiling Lib              ( Main.hs, Main.o, Main.dyn_o )
      instead of:
      $ ghc Main.hs -dynamic-too
      [1 of 1] Compiling Lib              ( Main.hs, Main.o )
  17. 12 Apr, 2019 1 commit
  18. 11 Apr, 2019 1 commit
    • Carter Schonwald's avatar
      removing x87 register support from native code gen · 42504f4a
      Carter Schonwald authored
      * simplifies registers to have GPR, Float and Double, by removing the SSE2 and X87 Constructors
      * makes -msse2 assumed/default for x86 platforms, fixing a long standing nondeterminism in rounding
      behavior in 32bit haskell code
      * removes the 80bit floating point representation from the supported float sizes
      * theres still 1 tiny bit of x87 support needed,
      for handling float and double return values in FFI calls  wrt the C ABI on x86_32,
      but this one piece does not leak into the rest of NCG.
      * Lots of code thats not been touched in a long time got deleted as a
      consequence of all of this
      all in all, this change paves the way towards a lot of future further
      improvements in how GHC handles floating point computations, along with
      making the native code gen more accessible to a larger pool of contributors.
  19. 10 Apr, 2019 1 commit