1. 07 Apr, 2016 1 commit
  2. 09 Feb, 2016 2 commits
    • Ben Gamari's avatar
      Unset GREP_OPTIONS in build system · bfec4a6a
      Ben Gamari authored
      Test Plan: GREP_OPTIONS=--blah ./validate
      
      Reviewers: austin, thomie
      
      Reviewed By: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1887
      
      GHC Trac Issues: #11530
      bfec4a6a
    • thomie's avatar
      Early error when crosscompiling + haddock/docs · 04fb7813
      thomie authored
      When CrossCompiling=YES or Stage1Only=YES, building the haddocks and the
      User's Guide should be skipped, because haddock and mkUserGuidePart
      depend on the GHC API.
      See Note [No stage2 packages when CrossCompiling or Stage1Only] for
      details.
      
      There are several places in the build system where the variables
      HADDOCK_DOCS and BUILD_SPHINX_* are checked. Instead of also checking
      for the variables CrossCompiling or Stage1Only in all those places,
      `make` will now exit with a nice error message when the user requests
      the impossible.
      
      Reviewers: rwbarton, austin, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1882
      04fb7813
  3. 27 Jan, 2016 1 commit
    • Tamar Christina's avatar
      Enable RemoteGHCi on Windows · 44a5d51a
      Tamar Christina authored
      Makes the needed changes to make RemoteGHCi work on Windows.
      The approach passes OS Handles areound instead of the Posix Fd
      as on Linux.
      
      The reason is that I could not find any real documentation about
      the behaviour of Windows w.r.t inheritance and Posix FDs.
      
      The implementation with Fd did not seem to be able to find the Fd
      in the child process. Instead I'm using the much better documented
      approach of passing inheriting handles.
      
      This requires a small modification to the `process` library.
      https://github.com/haskell/process/pull/52
      
      Test Plan: ./validate On Windows x86_64
      
      Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
      
      Reviewed By: simonmar
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1836
      
      GHC Trac Issues: #11100
      44a5d51a
  4. 18 Jan, 2016 1 commit
  5. 10 Jan, 2016 1 commit
  6. 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
  7. 04 Jan, 2016 1 commit
    • thomie's avatar
      Build system: delete ghc-pwd · 4c56ad36
      thomie authored
      On Windows, with msys2, `pwd` works (as can be seen by the use of `pwd`
      that slipped into the validate script), so there is really no need for
      `ghc-pwd` anymore.
      
      Test Plan: try it
      
      Reviewers: austin, bgamari, Phyx
      
      Reviewed By: Phyx
      
      Subscribers: Phyx, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1731
      4c56ad36
  8. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  9. 19 Dec, 2015 1 commit
  10. 17 Dec, 2015 4 commits
    • thomie's avatar
      Build system: allow bindist without docs · 116ba5e7
      thomie authored
      Useful for testing 'make binary-dist-prep' when HADDOCK_DOCS=NO.
      
      Reviewed by: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1648
      116ba5e7
    • thomie's avatar
      Build system: also put scripts in libexecdir/bin · c1bd3d44
      thomie authored
      This follows a similar change in
      4905b83a, where binaries are installed
      in libexecdir/bin instead of libexecdir.
      
      This fixes a problem with ghc not able to find ghc-split, when
      SplitObjs=YES.
      c1bd3d44
    • Simon Marlow's avatar
      Fix libffi dependency, and remove redundant LibFFI.hsc · 27f47cda
      Simon Marlow authored
      LibFFI.hsc was moved to libraries/ghci/GHCi/FFI.hsc, I just forgot to
      remove the old one.  We also need an explicit dependency on libffi,
      which moves from compiler/ghc.mk to the top-level ghc.mk (because
      libraries/ghci/ghc.mk is auto-generated).
      27f47cda
    • 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
  11. 06 Dec, 2015 1 commit
  12. 01 Dec, 2015 1 commit
    • thomie's avatar
      Build system: Add stage specific SRC_HC_(WARNING_)OPTS · 14d0f7f1
      thomie authored
      * Add stage specific versions of SRC_HC_OPTS. These are currently only
        used for -Werror. The previous combination of GhcStage2HcOpts and
        GhcLibHcOpts didn't apply to utils/*.
      
      * Add stage specific versions of SRC_HC_WARNING_OPTS. These will later be
        used for new warning supression flags that should not be passed to the
        bootstrap compiler.
      
      * Move -Wall (and -Werror) related code back to mk/warnings.mk, where it
        was before 987d5427. Now all warning related code is nicely together.
        Include mk/warnings.mk after mk/custom-settings.mk to make this work.
      
      Reviewed By: bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1536
      14d0f7f1
  13. 16 Nov, 2015 1 commit
  14. 07 Nov, 2015 1 commit
  15. 03 Nov, 2015 1 commit
    • thomie's avatar
      Build system: renable -Wall on validate (base) · 987d5427
      thomie authored
      Problem: 'SRC_HC_OPTS += -Wall' in 'mk/warnings.mk' was getting
      overwritten by 'SRC_HC_OPTS = ...' in 'mk/flavours/*.mk'.
      
      It didn't affect the compiler or most other libraries, because most
      .cabal files define 'ghc-options: -Wall'.
      
      Bug introduced in commit
      2c24fd70, when moving validate settings
      from 'mk/validate-settings.mk' to 'mk/flavours/validate.mk'.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D1425
      987d5427
  16. 01 Nov, 2015 1 commit
  17. 30 Oct, 2015 1 commit
  18. 29 Oct, 2015 1 commit
    • thomie's avatar
      Revert "Build system: don't create mk/are-validating.mk" · fa587316
      thomie authored
      Summary:
      This reverts commit aecf4a5f.
      
      It turns out the Simons are relying on 'mk/are-validating.mk', see
      D1307.
      
      The workflow they are using is:
        * run ./validate
        * find a bug in the compiler
        * try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
          of 'mk/are-validating.mk', this uses the same build settings as validate.
        * continue ./validate (--no-clean)
      
      I suggested two alternatives:
      
        A. run 'make 1 Validating=YES' instead of 'make 1'
      
           Problem: when running `./validate --fast` or `./validate --hpc`
           instead of a normal `./validate`, validate sets ValidateSpeed and
           ValdateHpc in mk/are-validating.mk. You would for example have to run
           'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
           same build settings as `./validate --fast`, which is entirely too long and
           error prone.
      
        B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
           'mk/validate.mk'.
      
           Problems:
            * any other settings you have in build.mk will also get used.
            * the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
              clear.
            * it is easy to forget to include 'mk/validate.mk'.
            * the build system again doesn't have access to the ValidateSpeed and
              ValdateHpc settings set by validate.
      
      Neither of these two options is entirely satisfactory.
      
      Reviewers: austin, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1383
      fa587316
  19. 25 Oct, 2015 1 commit
    • Alan Zimmerman's avatar
      Provide a utility to check API Annotations · 43751b24
      Alan Zimmerman authored
      It is difficult for GHC developers to know if they have broken the API
      Annotations.
      
      This patch provides a utility that can be used as a test to show up
      errors in the API Annotations.
      
      It is based on the current tests for ghc-api/annotations which can parse
      a file using the just-built GHC API, and check that no annotations are
      disconnected from the ParsedSource in the output.
      
      In addition, it should be able to dump the annotations to a file, so a
      new feature developer can check that all changes to the parser do
      provide annotations.
      
      Trac ticket: #10917
      
      Test Plan: ./validate
      
      Reviewers: hvr, thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1368
      
      GHC Trac Issues: #10917
      43751b24
  20. 22 Oct, 2015 1 commit
  21. 13 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
      freak out if using a `Data` instance that produces a `Constr` (by means of
      `toConstr`) using a function name instead of a data constructor name. While
      such `Data` instances are somewhat questionable, they are nevertheless present
      in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
      aware of their existence.
      
      In order to properly distinguish strings which represent variables (as opposed
      to data constructors), it was necessary to move functionality from `Lexeme` (in
      `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
      `bin-package-db`).
      
      Reviewed By: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1313
      
      GHC Trac Issues: #10796
      d2f9972a
  22. 04 Oct, 2015 1 commit
  23. 03 Oct, 2015 2 commits
  24. 08 Sep, 2015 3 commits
    • thomie's avatar
      Build system: check for inconsistent settings (#10157) · 1b8eca18
      thomie authored
      `configure` currently detects when the docbook and hscolour tools aren't
      available, and instead of failing outright (as it does for missing alex
      and happy), sets some variables in mk/config.mk to tell `make` not to
      build the documentation.
      
      Sometimes, however, you want to really make sure all documentation gets
      built, fully colourized. For example when making a release. To do so,
      you can override the mentioned variables from mk/config.mk in
      mk/build.mk (e.g. set HSCOLOUR_SRCS=YES).
      
      This patch adds some error checking to make sure that doing so will not
      result in weird build failures when those tools are still missing.
      
      Test Plan: ran `make` a couple of times, with different mk/config.mk settings.
      
      Reviewed by: austin
      
      Differential Revision: https://phabricator.haskell.org/D1232
      1b8eca18
    • thomie's avatar
      Build system: cleanup BUILD_DIRS + add lots of Notes · 8be43dd9
      thomie authored
      Summary:
      See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in.
      See Note [Stage1Only vs stage=1] in mk/config.mk.in.
      See Note [No stage2 packages when CrossCompiling or Stage1Only].
      
      Also:
        * use stage2 to build mkUserGuidePart, as was probably intended.
          Now the following represent the same set of packages:
          - packages that we build with ghc-stage2
          - packages that depend on the ghc library
          Those packages are: haddock, mkUserGuidePart and ghctags.
        * don't let utils that don't depend on the ghc library depend on its
          package-data.mk file. Instead, let those utils directly depend on
          the package-data.mk files of the stage1 packages. Not sure if it
          improves anything, but I found it easier to explain what's going on
          this way.
      
      (partially) reviewed by: austin
      
      Differential Revision: https://phabricator.haskell.org/D1218
      8be43dd9
    • thomie's avatar
      Build system: delete the InstallExtraPackages variable · a1586074
      thomie authored
      Just install all packages that are built. Don't make an exception for
      the dph and extra packages.
      
      You can control whether the dph and extra packages should be build using
      the variables BUILD_DPH and BUILD_EXTRA_PKGS. These variables didn't
      exist before. But now that they do, InstallExtraPackages isn't really
      needed anymore.
      
      Reviewed by: austin
      
      Differential Revision: https://phabricator.haskell.org/D1227
      a1586074
  25. 04 Sep, 2015 1 commit
  26. 21 Aug, 2015 1 commit
    • thomie's avatar
      Build system: simplify install.mk.in · 47493e60
      thomie authored
      This will allow fixing #1851 more easily
      ("make install-strip" should work).
      
      This reverts 57e2a81c:
        "On Cygwin, use a Cygwin-style path for /bin/install's destination"
      
      Update submodule haddock and hsc2hs.
      47493e60
  27. 17 Jul, 2015 1 commit
  28. 13 Jul, 2015 3 commits
    • thomie's avatar
      Build system: do not build stm and parallel by default · 392ff06d
      thomie authored
      stm and parallel have an 'extra' tag in the ./packages file, so would get
      added to PACKAGES_STAGE2 by default, and subsequently build by the stage2
      compiler.
      
      With this patch, this happens only when you set BUILD_EXTRA_PKGS=YES in
      build.mk. A normal validate still builds (and tests) the 'extra'
      packages, but they are skipped for `validate --fast`. Maybe this brings
      us closer to finishing within the 50 minute Travis limit as well.
      
      We can later try to give random, primitive and vector an 'extra' tag as
      well (now they have a 'dph' tag), but some tests will probably fail at
      first.
      
      Differential Revision: https://phabricator.haskell.org/D1065
      392ff06d
    • thomie's avatar
      Build system: delete REGULAR_INSTALL_DYNLIBS and INSTALL_DYNLIBS · 47ebe267
      thomie authored
      Ever since we ship xhtml, terminfo and haskeline (#8919), commit
      4caadb7c, REGULAR_INSTALL_DYNLIBS is
      always empty.
      
      REGULAR_INSTALL_PACKAGES =
        PACKAGES_STAGE1 + compiler + PACKAGES_STAGE2
      
      REGULAR_INSTALL_DYNLIBS =
        PACKAGES_STAGE1 + PACKAGES_STAGE2 - REGULAR_INSTALL_PACKAGES
      
      So we can delete it, and all the places where it is used. This
      simplifies ghc.mk a bit.
      
      Differential Revision: https://phabricator.haskell.org/D1062
      47ebe267
    • thomie's avatar
      Build system: comments only [skip ci] · 2e52057a
      thomie authored
      2e52057a
  29. 02 Jul, 2015 1 commit
  30. 22 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Rename $1_$2_$3_LIB_NAME to LIB_FILE. · 01f7e440
      Edward Z. Yang authored
      Summary:
      When we introduced user-friendly library names
      (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of
      unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
      be written out by ghc-cabal, $1_$2_LIB_NAME.
      
      What I didn't realize at the time was that this conflicts
      with an existing variable in the build system, $1_$2_$3_LIB_NAME,
      which (confusingly) refers to something like
      'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'.  This is pretty
      confusing (despite never conflicting), so I renamed this variable
      to LIB_FILE for enhanced greppability.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1002
      01f7e440
  31. 20 Jun, 2015 1 commit