1. 29 Mar, 2017 1 commit
  2. 15 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Introduce putLogMsg · 086b514b
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      This factors out the repetition of (log_action dflags dflags) and will
      hopefully allow us to someday better abstract log output.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3334
      086b514b
  3. 09 Mar, 2017 1 commit
    • bitonic's avatar
      Allow compilation of C/C++/ObjC/ObjC++ files with module from TH · 0fac488c
      bitonic authored and Ben Gamari's avatar Ben Gamari committed
      The main goal is to easily allow the inline-c project (and
      similar projects such as inline-java) to emit C/C++ files to
      be compiled and linked with the current module.
      
      Moreover, `addCStub` is removed, since it's quite fragile. Most
      notably, the C stubs end up in the file generated by
      `CodeOutput.outputForeignStubs`, which is tuned towards
      generating a file for stubs coming from `capi` and Haskell-to-C
      exports.
      
      Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari
      
      Reviewed By: dfeuer, bgamari
      
      Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes
      
      Differential Revision: https://phabricator.haskell.org/D3280
      0fac488c
  4. 03 Mar, 2017 1 commit
    • Simon Marlow's avatar
      Add -fwhole-archive-hs-libs · a6874e54
      Simon Marlow authored and Ben Gamari's avatar Ben Gamari committed
      We're building a demo to show how to hot-swap Haskell code in a
      running process, and unfortunately it wasn't possible to convince GHC
      to generate the correct linker command line without this extra knob.
      
      Test Plan:
      Tested it on a hot-swapping demo (which is not released yet, but will
      be shortly)
      
      Reviewers: niteria, austin, erikd, JonCoens, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3136
      a6874e54
  5. 23 Feb, 2017 1 commit
  6. 03 Feb, 2017 1 commit
    • Sylvain Henry's avatar
      Ditch static flags · bbd3c399
      Sylvain Henry authored and Ben Gamari's avatar Ben Gamari committed
      This patch converts the 4 lasting static flags (read from the command
      line and unsafely stored in immutable global variables) into dynamic
      flags. Most use cases have been converted into reading them from a DynFlags.
      
      In cases for which we don't have easy access to a DynFlags, we read from
      'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
      It's not perfect (not thread-safe) but it is still better as we can
      set/unset these 4 flags before each run when using GHC API.
      
      Updates haddock submodule.
      
      Rebased and finished by: bgamari
      
      Test Plan: validate
      
      Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2839
      
      GHC Trac Issues: #8440
      bbd3c399
  7. 02 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Add support for StaticPointers in GHCi · eedb3df0
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Here we add support to GHCi for StaticPointers. This process begins by
      adding remote GHCi messages for adding entries to the static pointer
      table. We then collect binders needing SPT entries after linking and
      send the interpreter a message adding entries with the appropriate
      fingerprints.
      
      Test Plan: `make test TEST=StaticPtr`
      
      Reviewers: facundominguez, mboes, simonpj, simonmar, goldfire, austin,
      hvr, erikd
      
      Reviewed By: simonpj, simonmar
      
      Subscribers: RyanGlScott, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2504
      
      GHC Trac Issues: #12356
      eedb3df0
  8. 21 Jan, 2017 1 commit
    • niteria's avatar
      Always use -Xlinker for -rpath · f9ccad23
      niteria authored
      Currently we use `-Wl` which takes a list of
      comma-separated options. Unfortunately that
      breaks when you use it with `-rpath` and
      a path that has commas in them.
      Buck, the build system, produces paths with
      commas in them.
      
      `-Xlinker` doesn't have this disadvantage
      and as far as I can tell is supported by
      both `gcc` and `clang`. Anecdotally `nvcc`
      supports `-Xlinker`, but not `-Wl`.
      
      Test Plan: ./validate, harbourmaster
      
      Reviewers: nomeata, simonmar, austin, bgamari, hvr
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2971
      f9ccad23
  9. 10 Jan, 2017 2 commits
  10. 20 Dec, 2016 1 commit
  11. 19 Dec, 2016 1 commit
  12. 18 Dec, 2016 1 commit
  13. 29 Nov, 2016 1 commit
  14. 11 Nov, 2016 2 commits
    • Ben Gamari's avatar
      Pass -no-pie to GCC · d421a7e2
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      This is a second attempt at D2691. This attempt constrasts with D2691 in that
      it preserves the "does gcc support -no-pie" flag in settings, allowing this to
      be reconfigured by `configure` during installation of a binary distribution.
      Thanks for @rwbarton for drawing attention to this issue.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, erikd
      
      Reviewed By: erikd
      
      Subscribers: thomie, rwbarton, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2693
      
      GHC Trac Issues: #12759
      d421a7e2
    • Ben Gamari's avatar
      Revert "Pass -no-pie to GCC" · 60bb9d1c
      Ben Gamari authored
      This reverts commit bae4a55b.
      
      This will be superceded by D2693.
      60bb9d1c
  15. 10 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Pass -no-pie to GCC · bae4a55b
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      Test Plan: Validate
      
      Reviewers: hvr, austin
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2691
      
      GHC Trac Issues: #12759
      bae4a55b
  16. 22 Oct, 2016 1 commit
    • Duncan Coutts's avatar
      Add and use a new dynamic-library-dirs field in the ghc-pkg info · f41a8a36
      Duncan Coutts authored
      Summary:
      Build systems / package managers want to be able to control the file
      layout of installed libraries. In general they may want/need to be able
      to put the static libraries and dynamic libraries in different places.
      The ghc-pkg library regisrtation needs to be able to handle this.
      
      This is already possible in principle by listing both a static lib dir
      and a dynamic lib dir in the library-dirs field (indeed some previous
      versions of Cabal did this for shared libs on ELF platforms).
      
      The downside of listing both dirs is twofold. There is a lack of
      precision, if we're not careful with naming then we could end up
      picking up the wrong library. The more immediate problem however is
      that if we list both directories then both directories get included
      into the ELF and Mach-O shared object runtime search paths. On ELF this
      merely slows down loading of shared libs (affecting prog startup time).
      On the latest OSX versions this provokes a much more serious problem:
      that there is a rather low limit on the total size of the section
      containing the runtime search path (and lib names and related) and thus
      listing any unnecessary directories wastes the limited space.
      
      So the solution in this patch is fairly straightforward: split the
      static and dynamic library search paths in the ghc-pkg db and its use
      within ghc. This is a traditional solution: pkg-config has the same
      static / dynamic split (though it describes in in terms of private and
      public, but it translates into different behaviour for static and
      dynamic linking).
      
      Indeed it would make perfect sense to also have a static/dynamic split
      for the list of the libraries to use i.e. to have dynamic variants of
      the hs-libraries and extra-libraries fields. These are not immediately
      required so this patch does not add it, but it is a reasonable
      direction to follow.
      
      To handle compatibility, if the new dynamic-library-dirs field is not
      specified then its value is taken from the library-dirs field.
      
      Contains Cabal submodule update.
      
      Test Plan:
      Run ./validate
      
      Get christiaanb and carter to test it on OSX Sierra, in combination
      with Cabal/cabal-install changes to the default file layout for
      libraries.
      
      Reviewers: carter, austin, hvr, christiaanb, bgamari
      
      Reviewed By: christiaanb, bgamari
      
      Subscribers: ezyang, Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2611
      
      GHC Trac Issues: #12479
      f41a8a36
  17. 09 Oct, 2016 1 commit
  18. 08 Oct, 2016 2 commits
  19. 02 Oct, 2016 1 commit
    • Nicolas Trangez's avatar
      Turn `__GLASGOW_HASKELL_LLVM__` into an integer again · b0d53a83
      Nicolas Trangez authored and Ben Gamari's avatar Ben Gamari committed
      In GHC < 8.0.1, the value of `__GLASGOW_HASKELL_LLVM__`, exposed
      through the preprocessor when compiled with `-fllvm`, was an integer
      value, encoded according to some rules specified in the user guide.
      
      Due to an oversight, in GHC 8.0.1 the value of this define became a
      tuple, exposed as e.g. `(3, 7)`. This was an unintended regression.
      
      This patch turns the value of the `__GLASGOW_HASKELL_LLVM__` definition
      into a single integer again, but changes the formatting of said number
      slightly. Before, any LLVM version where the major or minor component >=
      10 would cause ambiguous values for `__GLASGOW_HASKELL_LLVM__`. With
      this patch, the value is in line with `__GLASGOW_HASKELL__`, adding a
      padding `0` in-between major and minor component if applicable (we
      assume no minors >= 100 will ever exist).
      
      The documentation in the user guide is updated accordingly, and a
      reference is made in the 8.0.2 release notes.
      
      Test Plan: validate
      
      Reviewers: bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2552
      
      GHC Trac Issues: #12628
      b0d53a83
  20. 06 Jun, 2016 1 commit
    • niteria's avatar
      Use UniqDFM for HomePackageTable · 3042a9d8
      niteria authored
      This isn't strictly necessary for deterministic ABIs.
      The results of eltsHpt are consumed in two ways:
      1) they determine the order of linking
      2) if you track the data flow all the family instances get put in
         FamInstEnvs, so the nondeterministic order is forgotten.
      3) same for VectInfo stuff
      4) same for Annotations
      
      The problem is that I haven't found a nice way to do 2. in
      a local way and 1. is nice to have if we went for deterministic
      object files. Besides these maps are keyed on ModuleNames so they
      should be small relative to other things and the overhead should
      be negligible.
      
      As a bonus we also get more specific names.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, hvr, ezyang, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2300
      
      GHC Trac Issues: #4012
      3042a9d8
  21. 30 Mar, 2016 2 commits
  22. 28 Mar, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Scrap DEC OSF/1 support · f911358b
      Herbert Valerio Riedel authored
      DEC OSF/1 (aka Tru64 UNIX) has been discontinued a few years ago already[1].
      
      This removes the undoubtedly bitrotten support for `OSOsf3 :: OS` from GHC's
      code-base.
      
      Support for `ArchAlpha :: Arch` may be removed at some later point, as there
      may still be users out there running a more or less recent Linux/alpha
      distribution on their more-than-a-decade old Alpha hardware...
      
       [1]: https://en.wikipedia.org/wiki/Tru64_UNIX
      f911358b
  23. 24 Mar, 2016 1 commit
  24. 16 Mar, 2016 1 commit
    • Erik de Castro Lopo's avatar
      DriverPipeline: Fix 'unused arguments' warnings from Clang · 46f9a476
      Erik de Castro Lopo authored
      When using Clang as the C compiler, over 100 tests were failing
      due to Clang reporting that some command line arguments were not
      being used. These warnings only occur when Clang is compiling
      assembler files which happens in two places, one of which already
      conditionally adding `-Qunused-arguments` to the command line when
      the compiler was Clang. This fixes the other.
      
      Test Plan: validate with clang as the C compiler
      
      Reviewers: bgamari, hvr, austin, rwbarton
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1998
      
      GHC Trac Issues: #11684
      46f9a476
  25. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored and Herbert Valerio Riedel's avatar Herbert Valerio Riedel committed
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  26. 24 Jan, 2016 1 commit
  27. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  28. 08 Jan, 2016 1 commit
    • Simon Marlow's avatar
      Enable stack traces with ghci -fexternal-interpreter -prof · 6be09e88
      Simon Marlow authored
      Summary:
      The main goal here is enable stack traces in GHCi.  After this change,
      if you start GHCi like this:
      
        ghci -fexternal-interpreter -prof
      
      (which requires packages to be built for profiling, but not GHC
      itself) then the interpreter manages cost-centre stacks during
      execution and can produce a stack trace on request.  Call locations
      are available for all interpreted code, and any compiled code that was
      built with the `-fprof-auto` familiy of flags.
      
      There are a couple of ways to get a stack trace:
      
      * `error`/`undefined` automatically get one attached
      * `Debug.Trace.traceStack` can be used anywhere, and prints the current
        stack
      
      Because the interpreter is running in a separate process, only the
      interpreted code is running in profiled mode and the compiler itself
      isn't slowed down by profiling.
      
      The GHCi debugger still doesn't work with -fexternal-interpreter,
      although this patch gets it a step closer.  Most of the functionality
      of breakpoints is implemented, but the runtime value introspection is
      still not supported.
      
      Along the way I also did some refactoring and added type arguments to
      the various remote pointer types in `GHCi.RemotePtr`, so there's
      better type safety and documentation in the bridge code between GHC
      and ghc-iserv.
      
      Test Plan: validate
      
      Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1747
      
      GHC Trac Issues: #11047, #11100
      6be09e88
  29. 31 Dec, 2015 3 commits
    • Herbert Valerio Riedel's avatar
      Drop redundant/explicit `=1` in `-DFOO=1` flags · 0d207378
      Herbert Valerio Riedel authored
      Quoting the POSIX standard for the `-D` C compiler flag:
      
        -D  name[=value]
      
            Define name as if by a C-language #define directive.
            If no `=value` is given, a value of 1 shall be used.
            [...]
      
      Removing this explicit `=1` definition from `-D` flags which are used to
      define boolean macro constants makes the CLI invocation a bit more
      idiomatic and reduces visual noise in debugging output
      (flags containing `=`s are additionally put in single-quotes by GHC)
      0d207378
    • Herbert Valerio Riedel's avatar
      Use 0/1 instead of YES/NO as `__GLASGOW_HASKELL_TH__` macro value · eae40e16
      Herbert Valerio Riedel authored
      Using `YES`/`NO` causes all sorts of problems as CPP doesn't work on
      symbolic tokens but rather on scalar values.
      
      A use like
      
         #if __GLASGOW_HASKELL_TH__==YES
         {-# LANGUAGE TemplateHaskell #-}
         #endif
      
      doesn't do what one may naively expect, and neither does
      
         #if __GLASGOW_HASKELL_TH__
         {-# LANGUAGE TemplateHaskell #-}
         #endif
      
      *unless* `YES` happens to evaluate to a non-zero scalar.
      
      `__GLASGOW_HASKELL_TH__ was originally introduced via D396 / #9734.
      
      Fixes #11322
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D1723
      eae40e16
    • Herbert Valerio Riedel's avatar
      Drop redundant `-D__GLASGOW_HASKELL__=...` flag · 351dea4a
      Herbert Valerio Riedel authored
      In 3549c952 a `include/ghcversions.h` include
      file was introduced which defines `__GLASGOW_HASKELL__` as well.
      
      So there's no need to define it twice.
      351dea4a
  30. 29 Dec, 2015 1 commit
  31. 27 Dec, 2015 1 commit
  32. 19 Dec, 2015 1 commit
  33. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  34. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536