1. 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
  2. 06 Dec, 2015 1 commit
  3. 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
  4. 16 Nov, 2015 1 commit
  5. 07 Nov, 2015 1 commit
  6. 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
  7. 01 Nov, 2015 1 commit
  8. 30 Oct, 2015 1 commit
  9. 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
  10. 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
  11. 22 Oct, 2015 1 commit
  12. 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
  13. 04 Oct, 2015 1 commit
  14. 03 Oct, 2015 2 commits
  15. 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
  16. 04 Sep, 2015 1 commit
  17. 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
  18. 17 Jul, 2015 1 commit
  19. 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
  20. 02 Jul, 2015 1 commit
  21. 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
  22. 20 Jun, 2015 1 commit
  23. 09 Jun, 2015 2 commits
    • thomie's avatar
      make sdist: distclean testsuite for real (#10406) · 5828457d
      thomie authored
      5828457d
    • Austin Seipp's avatar
      build: Clean testsuite before sdist · a48167ea
      Austin Seipp authored
      When making the `sdist` tarball, we don't really need anything inside
      $(TOP)/testsuite in order to do our thing. So make sure we clean it
      first to avoid situations like #10406.
      
      With D917 landed, this can actually avoided entirely by fixing the
      official release process to instead build an `sdist` //first// from the
      clean git repository and then build that (to fixpoint) and test it. Then
      the originall clean tarball can be shipped.
      
      But it's nice to be safe in the general case where someone might want to
      (in the future) `sdist` out of their build tree.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: thomie
      
      Differential Revision: https://phabricator.haskell.org/D956
      
      GHC Trac Issues: #10406
      a48167ea
  24. 04 Jun, 2015 1 commit
    • thomie's avatar
      Build: ./boot && ./configure && make sdist (#8723) · 092082e7
      thomie authored
      Make it possible to run `make sdist` right after configure, without completing
      a complete build first.
      
      Test Plan:
      I compared the contents of the created `.tar.bz2` files in the `sdistprep`
      directory, after running `make sdist` both before and after completing a full
      build, using `diff -r`. There weren't any differences (after applying the
      patches from D914).
      
      Note that the `.tar.bz2` files were not exactly the same size, but they aren't
      either when tarring and bzipping the same directory twice. It seems tarring
      and bzipping is not deterministic (on my system).
      
      Differential Revision: https://phabricator.haskell.org/D917
      092082e7
  25. 02 Jun, 2015 1 commit
  26. 30 May, 2015 6 commits
  27. 11 May, 2015 1 commit
    • Edward Z. Yang's avatar
      Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. · f16ddcee
      Edward Z. Yang authored
      Summary:
      This commit adds stage 1 support for Template Haskell
      quoting, e.g. [| ... expr ... |], which is useful
      for authors of quasiquoter libraries that do not actually
      need splices.  The TemplateHaskell extension now does not
      unconditionally fail; it only fails if the renamer encounters
      a splice that it can't run.
      
      In order to make sure the referenced data structures
      are consistent, template-haskell is now a boot library.
      There are some minor BC changes to template-haskell to make it boot
      on GHC 7.8.
      
      Note for reviewer: big diff changes are simply code
      being moved out of an ifdef; there was no other substantive
      change to that code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D876
      
      GHC Trac Issues: #10382
      f16ddcee
  28. 09 May, 2015 2 commits
    • Edward Z. Yang's avatar
      Revert stage 1 template-haskell. This is a combination of 5 commits. · 5c459eef
      Edward Z. Yang authored
      Revert "Quick fix: drop base bound on template-haskell."
      
      This reverts commit 3c70ae03.
      
      Revert "Always do polymorphic typed quote check, c.f. #10384"
      
      This reverts commit 9a43b2c1.
      
      Revert "RnSplice's staging test should be applied for quotes in stage1."
      
      This reverts commit eb0ed403.
      
      Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler."
      
      This reverts commit 21c72e7d.
      
      Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382."
      
      This reverts commit 28257cae.
      5c459eef
    • Edward Z. Yang's avatar
      Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. · 28257cae
      Edward Z. Yang authored
      Summary:
      This commit adds stage 1 support for Template Haskell
      quoting, e.g. [| ... expr ... |], which is useful
      for authors of quasiquoter libraries that do not actually
      need splices.  The TemplateHaskell extension now does not
      unconditionally fail; it only fails if the renamer encounters
      a splice that it can't run.
      
      In order to make sure the referenced data structures
      are consistent, template-haskell is now a boot library.
      
      In the following patches, there are:
      
          - A few extra safety checks which should be enabled
            in stage1
          - Separation of the th/ testsuite into quotes/ which
            can be run on stage1
      
      Note for reviewer: big diff changes are simply code
      being moved out of an ifdef; there was no other substantive
      change to that code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D876
      
      GHC Trac Issues: #10382
      28257cae