1. 06 Dec, 2018 5 commits
    • Tobias Decking's avatar
      Add fusion rules for the zipWith functions in base (#15263) · fb669f51
      Tobias Decking authored
      This patch will allow `zip3` and `zipWith3` in `GHC.List` as well
      as `zipWith4`, `zipWith5`, `zipWith6` and `zipWith7` in `Data.OldList` to fuse.
      These rules are kept in a similar style as the rules for `zip` and `zipWith`.
      Added a corresponding test case.
      Test Plan: validate
      Reviewers: hvr, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rockbmb, rwbarton, carter
      GHC Trac Issues: #15263
      Differential Revision: https://phabricator.haskell.org/D5241
    • Ben Gamari's avatar
      Windows: Use the "big" PE object format on amd64 · 1ef90f99
      Ben Gamari authored
      Test Plan: Do full build on Windows.
      Reviewers: AndreasK, Phyx
      Reviewed By: AndreasK
      Subscribers: rwbarton, erikd, carter
      GHC Trac Issues: #15934
      Differential Revision: https://phabricator.haskell.org/D5383
    • Sebastian Graf's avatar
      Don't use a generic apply thunk for known calls · dc54c07c
      Sebastian Graf authored
      Currently, an AP thunk like `sat = f a b c` will not have its own entry
      point and info pointer and will instead reuse a generic apply thunk
      like `stg_ap_4_upd`.
      That's great from a code size perspective, but if `f` is a known
      function, a specialised entry point with a plain call can be much faster
      than figuring out the arity and doing dynamic dispatch.
      This looks at `f`s arity to figure out if it is a known function and if so, it
      will not lower it to a generic apply function.
      Benchmark results are encouraging: No changes to allocation, but 0.2% less
      counted instructions.
      Test Plan: Validates locally
      Reviewers: simonmar, osa1, simonpj, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, carter
      GHC Trac Issues: #16005
      Differential Revision: https://phabricator.haskell.org/D5414
    • Simon Peyton Jones's avatar
      Remove a tcTrace · 081f44bf
      Simon Peyton Jones authored
      This tcTrace, in tcTyFamInstEqn, caused a knot-tying loop, because
      it was printing a type after zonking-to-Type.  Easy solution: don't
      do that.
    • Simon Peyton Jones's avatar
      Tests Trac #14847 · 91c4e71f
      Simon Peyton Jones authored
  2. 05 Dec, 2018 2 commits
    • Alexander Vershilov's avatar
      Remove explicit recursion in retainer profiling (fixes #14758) · 5f1d949a
      Alexander Vershilov authored
      Retainer profiling contained a recursion that under
      certain circumstances could lead to the stack overflow
      in C code.
      The idea of the improvement is to keep an explicit stack for the
      object, more precise to reuse existing stack, but allow new type of
      objects to be stored there.
      There is no reliable reproducer that is not a big program
      but in some cases foldr (+) 0 [1..10000000] can work.
      Reviewers: bgamari, simonmar, erikd, osa1
      Reviewed By: bgamari, osa1
      Subscribers: osa1, rwbarton, carter
      GHC Trac Issues: #14758
      Differential Revision: https://phabricator.haskell.org/D5351
    • Simon Peyton Jones's avatar
      Remove duplicates in -ddump-minimial-imports · 84cba4bc
      Simon Peyton Jones authored
      This fixes Trac #15994.
      Previously RdrName.gresToAvailInfo assumed that the input list
      of GREs had no duplicates. I accidentally broke this precondition
      in this refactoring:
          commit 6353efc7
          Date:   Thu Nov 22 14:48:05 2018 -0500
          Fix unused-import warnings
          This patch fixes a fairly long-standing bug (dating back to 2015) in
          RdrName.bestImport, namely
      (There was an ASSERT, but it's usually switched off in stage2.  It
      tripped when I switched stage2 assertions on.)
      The fix is straightforward: account for dups in gresToAvailInfo.
  3. 04 Dec, 2018 3 commits
    • Tamar Christina's avatar
      linker: store entire link map and use it. · a8b7cef4
      Tamar Christina authored
      This fixes a corner case in which we have seen the symbol multiple times in
      different static libraries, but due to a depencency we end up loading the
      symbol from a library other than the first one.
      Previously the runtime linker would only track symbols from the first
      library and did not store the full link map.  In this case it was unable
      to find the address for the symbols in the second library during delay
      This change stores the address of all symbols seen so a full link map
      is generated, such that when we make a different decision later than what
      was expected we're able to still correctly load the library.
      Test Plan: ./validate, new testcase T15894
      Reviewers: angerman, bgamari, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15894
      Differential Revision: https://phabricator.haskell.org/D5353
    • Alec Theriault's avatar
      Hadrian: include 'findPtr' via find-ptr cabal flag · 924026e0
      Alec Theriault authored
      This is the latest in the 'findPtr' saga. See
        * 900c47f8
        * 561748cb
      for the previous attempts. The problem with re-using the 'debug'
      cabal flag for the purpose of forcing inclusion of 'findPtr' occurs
      when 'debug' is one of the RTS ways, but RTS is not being compiled
      with '-DDEBUG':
        * the 'debug' flag gets passed to cabal, signalling to build
          'rts' with the debug flavour, but also forcing inclusion of
          the 'findPtr'/'_findPtr' symbol
        * since '-DDEBUG' isn't enabled, that symbol doesn't show up in
          the libraries, so executable that depend on 'rts' (everything)
          will end up always requiring 'findPtr'/'_findPtr' but 'rts' won'y
          provide it!
      The fix is simple: create a a new 'find-ptr' cabal-flag whose only
      purpose is forcing '-Wl,-u,findPtr'/'-Wl,-u,_findPtr'. Then, enable that
      flag when the RTS is being compiled with '-DDEBUG'
      Test Plan: ./hadrian/build.sh -c # on mac
      Reviewers: alpmestan, snowleopard, bgamari, erikd, simonmar, Phyx
      Reviewed By: alpmestan, snowleopard, Phyx
      Subscribers: Phyx, rwbarton, carter
      GHC Trac Issues: #15956
      Differential Revision: https://phabricator.haskell.org/D5404
    • Roland Senn's avatar
      Improve test T14452 for Windows · 6090002e
      Roland Senn authored
      Summary: Under Windows all parameters to gcc are enclosed in quotes, opposite to
      Linux, where the quotes are missing. Therefore in the test, we remove all
      quotes in the stdout file with sed.
      Test Plan: make test TEST=T14452
      Reviewers: osa1, hvr, bgamari, monoidal, Phyx, simonpj
      Reviewed By: Phyx
      Subscribers: rwbarton, carter
      GHC Trac Issues: #14452
      Differential Revision: https://phabricator.haskell.org/D5398
  4. 03 Dec, 2018 8 commits
    • Andreas Klebinger's avatar
      Bump nofib submodule · 51e56dd5
      Andreas Klebinger authored
      Test Plan: run nofib
      Reviewers: bgamari, tdammers
      Reviewed By: tdammers
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5396
    • Arnaud Spiwack's avatar
      Fix link name to a note · 920f1bdc
      Arnaud Spiwack authored
      Reviewers: goldfire, bgamari, tdammers
      Reviewed By: tdammers
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5399
    • Ryan Scott's avatar
      Add test cases for #7503, #14451 · aef5d825
      Ryan Scott authored
      At some point between 8.4 and 8.6, two things were fixed:
      * The entirety of #14451.
      * One of the test cases in #7503. I've added this as T7503a. The
        other test case from that ticket still does /not/ work, so we'll
        have to add T7503b some other day.
    • Simon Peyton Jones's avatar
      Comments only · a46511a8
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Introduce tcTypeKind, and use it · 03d48526
      Simon Peyton Jones authored
      In the type checker Constraint and * are distinct; and the function
      that takes the kind of a type should respect that distinction
      (Trac #15971).
      This patch implements the change:
      * Introduce Type.tcTypeKind, and use it throughout the type
        inference engine
      * Add new Note [Kinding rules for types] for the kinding
        rules, especially for foralls.
      * Redefine
          isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
        (it had a much more complicated definition before)
      Some miscellaneous refactoring
      * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
        in favour of TyCoRep.kindRep, kindRep_maybe
      * Rename Type.getRuntimeRepFromKind_maybe
        to getRuntimeRep_maybe
      I did some spot-checks on compiler perf, and it really doesn't
      budge (as expected).
    • Ryan Scott's avatar
      Fix embarrassing infinite loop in pprParendType · 89d80921
      Ryan Scott authored
      `pprParendType` was missing an explicit case for
      `EqualityT`, which caused it to fall through to a catch-all case
      that invokes `ppr`. But `ppr` itself does not have a case for a
      partial application of `EqualityT`, so //it// falls back to
      `pprParendType`, resulting in an infinite loop!
      The fix is simple: add a case for `EqualityT` in `pprParendType`.
      While I was in the neighborhood, I removed the catch-call case in
      `pprParendType` to make this sort of mistake less likely to happen
      in the future.
      Test Plan: make test TEST=T15985
      Reviewers: bgamari, monoidal, simonpj
      Reviewed By: monoidal, simonpj
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15985
      Differential Revision: https://phabricator.haskell.org/D5403
    • Ryan Scott's avatar
      Fix #15954 by rejigging check_type's order · 2e6cc3d0
      Ryan Scott authored
      Previously, `check_type` (which catches illegal uses of
      unsaturated type synonyms without enabling `LiberalTypeSynonyms`,
      among other things) always checks for uses of polytypes before
      anything else. There is a problem with this plan, however:
      checking for polytypes requires decomposing `forall`s and other
      invisible arguments, an action which itself expands type synonyms!
      Therefore, if we have something like:
      type A a = Int
      type B (a :: Type -> Type) = forall x. x -> x
      type C = B A
      Then when checking `B A`, `A` will get expanded to `forall x. x -> x`
      before `check_type` has an opportunity to realize that `A` is an
      unsaturated type synonym! This is the root cause of #15954.
      This patch fixes the issue by moving the case of `check_type` that
      detects polytypes to be //after// the case that checks for
      `TyConApp`s. That way, the `TyConApp` case will properly flag things
      like the unsaturated use of `A` in the example above before we ever
      attempt to check for polytypes.
      Test Plan: make test TEST=T15954
      Reviewers: simonpj, bgamari, goldfire
      Reviewed By: simonpj
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15954
      Differential Revision: https://phabricator.haskell.org/D5402
    • Alec Theriault's avatar
      Warn on all out-of-range literals in pats/exprs · 75a8349b
      Alec Theriault authored
      These changes were motivated by #13256. While poking around, I
      realized we weren't very consistent in our "-Woverflowed-literals"
      warnings. This patch fixes that by:
        * warning earlier on in the pipeline (ie. before we've desugared
          'Int' patterns into 'I# Int#')
        * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed
        * covering more pattern / expression forms
      4/6 of the warnings in the 'Overflow' test are due to this patch. The
      other two are mostly for completeness.
      Also fixed a missing empty-enumeration warning for 'Natural'.
      This warnings were tripped up by the 'Bounded Word' instance (see #9505),
      but the fix was obvious and simple: use unboxed word literals.
      Test Plan: make TEST=Overflow && make TEST=T10930
      Reviewers: hvr, bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #13256, #10930
      Differential Revision: https://phabricator.haskell.org/D5181
  5. 02 Dec, 2018 1 commit
    • Alp Mestanogullari's avatar
      update (CicleCI) CI script to work with ghc-ci · 93a3f907
      Alp Mestanogullari authored
      ghc-ci is a tiny webservice that acts as an intermediate between our
      CircleCI jobs on Gitlab and the actual builds running on CircleCI, so that
      the build script doesn't need to rely on any secret, which makes the whole
      setup fork-friendly.
      The concrete effect of this patch is to allow any fork of GHC on Gitlab to
      run CircleCI jobs.
  6. 01 Dec, 2018 6 commits
  7. 30 Nov, 2018 5 commits
    • David Eichmann's avatar
      Skip all performance tests if not in a git repo. · 6e24a0be
      David Eichmann authored
      Reviewers: bgamari, tdammers, osa1
      Reviewed By: tdammers
      Subscribers: osa1, tdammers, rwbarton, carter
      GHC Trac Issues: #15923
      Differential Revision: https://phabricator.haskell.org/D5367
    • Sebastian Graf's avatar
      Deduplicate decision to count thunks in `-ticky` · f10df65f
      Sebastian Graf authored
      Previously, the logic that checks whether a thunk has a counter or not
      was duplicated in multiple functions.
      This led to thunk enters being accounted to their enclosing functions in
      `StgCmmTicky.tickyEnterThunk`, because the outer call to
      `withNewTickyCounterThunk` didn't set the counter label for the thunk.
      And rightly so! `tickyEnterThunk` should only account thunk enters to a
      counter if `-ticky-dyn-thunk` is on.
      This patch extracts the logic that was already present in its most
      general form in `withNewTickyCounterThunk` into its own functions and
      lets all other call sites checking for `-ticky-dyn-thunk` call this new
      function named `thunkHasCounter` instead.
      Reviewers: bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5392
    • Alec Theriault's avatar
      Add 'Lift' instances for 'NonEmpty' and 'Void' · 47875bd4
      Alec Theriault authored
      Since 'NonEmpty' and 'Void' are now part of 'base', it makes
      sense that we put 'Lift' instances for them in 'template-haskell'.
      Not doing so is going to force users to define their own (possibly
      colliding) orphan instances downstream.
      Test Plan: ./validate
      Reviewers: goldfire, bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #15961
      Differential Revision: https://phabricator.haskell.org/D5391
    • Simon Peyton Jones's avatar
      Two tests for Trac #14230 · 80d665a1
      Simon Peyton Jones authored
    • Ryan Scott's avatar
      Accept T15828 test output · b1af0aed
      Ryan Scott authored
      This test output changed slightly due to commit
      2257a86d (which is expected).
  8. 29 Nov, 2018 10 commits
    • Chaitanya Koparkar's avatar
      Add a test case for #15962 · 8d7496c4
      Chaitanya Koparkar authored
      Test Plan: make test TEST=T15962
      Reviewers: RyanGlScott, bgamari
      Reviewed By: RyanGlScott
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15962
      Differential Revision: https://phabricator.haskell.org/D5393
    • Ryan Scott's avatar
      Make ghc-in-ghci support Hadrian · 30a363ae
      Ryan Scott authored
      Currently, `ghc-in-ghci` is hard-coded to only support
      the installation path of the `make`-based build system. There isn't
      a fundamental reason why this must be the case, however—it's just a
      matter of communicating which directories to look into.
      For the time being, I've hacked `utils/ghc-in-ghci/run.sh` to just
      check the default Hadrian installation path in addition to the `make`
      one. Disclaimer: I'm not well-versed in `bash`-fu, so it's possible
      that there is a better way to accomplish what I'm setting out to do.
      Suggestions welcome.
      Test Plan: ./utils/ghc-in-ghci/run.sh
      Reviewers: alpmestan, bgamari
      Reviewed By: alpmestan
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5390
    • Ryan Scott's avatar
      Allow containers-0.6, QuickCheck-2.12 in Hadrian · 8bffd580
      Ryan Scott authored
      Currently, Hadrian has restrictive upper bounds on
      `containers` and `QuickCheck` that prevents it from building with
      the latest versions of each respective library ( and There doesn't appear to be any good reason to do so,
      since Hadrian builds fine with them, so let's bump the upper version
      bounds accordingly.
      Test Plan: ./build/hadrian.sh
      Reviewers: bgamari, alpmestan, snowleopard
      Reviewed By: snowleopard
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5389
    • Chaitanya Koparkar's avatar
      Fix #15953 by consistently using dumpIfSet_dyn to print debug output · dcf1f926
      Chaitanya Koparkar authored
      In some modules we directly dump the debugging output to STDOUT
      via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file`
      is enabled, that output should be written to a file. Easily fixed.
      Certain tests (T3017, Roles3, T12763 etc.) expect part of the
      output generated by `-ddump-types` to be in 'PprUser' style. However,
      generally we want all other debugging output to use 'PprDump'
      style. `traceTcRn` and `traceTcRnForUser` help us accomplish this.
      This patch also documents some missing flags in the users guide.
      Reviewers: RyanGlScott, bgamari, hvr
      Reviewed By: RyanGlScott
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15953
      Differential Revision: https://phabricator.haskell.org/D5382
    • Victor Nawothnig's avatar
      Add missing since annotations · 9e3aaf8b
      Victor Nawothnig authored
      Reviewers: hvr, bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #15930
      Differential Revision: https://phabricator.haskell.org/D5379
    • mayac's avatar
      Fix #15828, from `More explicit foralls` · fe57a5ba
      mayac authored
      Fix a bug in commit 12eeb9 which permits the following:
      class C a where
        type T a b
      instance C (Maybe a) where
        type forall a b. T (Maybe a) b = b
      where instead, the user should write:
      instance C (Maybe a) where
        type forall b. T (Maybe a) b = b
      Update the users guide to discuss scoping of type variables in
      explicit foralls in type family instances.
      Test Plan: validate
      Reviewers: bgamari, goldfire, monoidal
      Reviewed By: goldfire
      Subscribers: monoidal, rwbarton, carter
      GHC Trac Issues: #15828
      Differential Revision: https://phabricator.haskell.org/D5283
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      Let's deal with the level-numbers part first:
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that ...
    • David Eichmann's avatar
      Hadrian: support dynamically linking ghc · 79d5427e
      David Eichmann authored
      * (#15837 point 5) Use the -rpath gcc option and using the $ORIGIN
      variable which the dynamic linker sets to the location of the ghc
      * (#15837 point 4) "-fPIC -dynamic" options are used when building ghc
      when either ghc or the rts have a dynamic way.
      * (#15837 point 7) "-shared -dynload deploy" options are only used when
      linking a library (no longer when linking a program).
      Reviewers: bgamari, alpmestan
      Reviewed By: alpmestan
      Subscribers: adamse, rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5281
    • Alp Mestanogullari's avatar
      Hadrian: bump Cabal submodule, install extra dynamic flavours of RTS · fb997160
      Alp Mestanogullari authored
      Previously, Hadrian was building all the appropriate dynamic ways for
      but they were not picked up and installed in the package database when
      we register the rts library. Since we use Cabal for registering
      packages and
      the .cabal files of packages as sources of truth for configuring and
      we ended up patching Cabal to add a new field,
      to specify those extra flavours to install in .cabal files:
      We now make use of this in rts.cabal.in to expose dynamic flavours
      behind a
      Cabal flag, which Hadrian will use whenever we are building a GHC
      flavour that
      requires dynamic libraries.
      This is all part of a larger plan to build a dynamic stage 2 GHC by
      like with make, which in turn will fix a lot of test failures. See
      Test Plan:
      hadrian/build.sh _build/stage1/lib/package.conf.d/rts-1.0.conf
      _build/stage1/lib/x86_64-.../ should contain many libHSrts-*.so
      Reviewers: snowleopard, DavidEichmann, bgamari, erikd, simonmar
      Reviewed By: snowleopard, DavidEichmann
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15837
      Differential Revision: https://phabricator.haskell.org/D5385
    • Simon Peyton Jones's avatar
      Test Trac #15943 · 1235ca95
      Simon Peyton Jones authored
      This test seems to work in HEAD