1. 26 Feb, 2017 9 commits
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
      3415bcaa
    • rwbarton's avatar
      tests: manually move some extra_files into *.T files · 98119f5a
      rwbarton authored
      Some of the *.T files were in libraries/hpc, so this contains an
      update to that submodule.
      98119f5a
    • rwbarton's avatar
      Remove extra_files entries for deleted tests · 8bb63c2e
      rwbarton authored
      8bb63c2e
    • rwbarton's avatar
      Manually move extra_files for tests T9579_* · 35b5790e
      rwbarton authored
      Summary: My script won't understand this.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3210
      35b5790e
    • Joachim Breitner's avatar
      Ensure that Literals are in range · 6dfc5ebf
      Joachim Breitner authored
      This commit fixes several bugs related to case expressions
      involving numeric literals which are not in the range of values of
      their (fixed-width, integral) type.
      
      There is a new invariant on Literal: The argument of a MachInt[64]
      or MachWord[64] must lie within the range of the corresponding
      primitive type Int[64]# or Word[64]#, as defined by the target machine.
      This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping
      the argument to the target type's range if necessary.
      
      Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245
      T10246"
      
      Trac issues: #9533, #10245, #10246, #13171
      
      Reviewers: simonmar, simonpj, austin, bgamari, nomeata
      
      Reviewed By: bgamari
      
      Subscribers: thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D810
      6dfc5ebf
    • Ben Gamari's avatar
      Add testcase for #13340 · 517ad201
      Ben Gamari authored
      Test Plan: Validate
      
      Reviewers: rwbarton, austin
      
      Reviewed By: rwbarton
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3215
      517ad201
    • Ben Gamari's avatar
      testsuite: Bump down T2762 number · d4b6deee
      Ben Gamari authored
      Although I'm really not convinced that measuring peak_megabytes_allocated of
      this test is reasonable.
      d4b6deee
    • Tamar Christina's avatar
      Load dependent dlls. · 41e54b4b
      Tamar Christina authored
      When the `GCC` driver envokes the pipeline a `SPEC` is used to determine
      how to configure the compiler and which libraries to pass along.
      
      For Windows/mingw, this specfile is
      https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h
      
      This has a lot of interesting things that we need to emulate in order to
      be able to link as many things out of the box as GCC. In particular this
      is why you never need to specify `-lgcc_s` when compiling, but you do
      when using `GHCi`.
      
      Unfortunately due to time constraints I can't set up the framework
      required in `GHC` to do this before the feature freeze.
      
      So I suggest this alternate implementation:
      When we load a dll, also bring it's dependencies into scope of the
      interpeter.
      
      This has pros and cons. Pro is, we'll fix many packages on hackage which
      specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which
      will bring `libgcc` into scope.
      
      The downside is, we'll be more lenient than GCC, in that the interpreter
      will link much easier since it has implicit dependencies in scope.
      Whereas for compilation to work you will have to specify it as an
      argument to GHC.
      
      This will make the Windows runtime linker more consistent with the unix
      ones. The difference in semantics came about because of the differences
      between `dlsym` and `GetProcAddress`.  The former seems to search the
      given library and all it's dependencies, while the latter only searches
      the export table of the library. So we need some extra manual work to
      search the dependencies which this patch provides.
      
      Test Plan:
      ```
      ./validate
      ```
      ```
      $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS
      -lstdc++ 2>&1 | grep "Loading dependency"
      ```
      
      ```
      $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS
      -Dl -RTS 2>&1 | grep "Loading dependency"
      Loading dependency *.exe -> GDI32.dll.
      Loading dependency GDI32.dll -> ntdll.dll.
      Loading dependency *.exe -> KERNEL32.dll.
      Loading dependency KERNEL32.dll -> KERNELBASE.dll.
      Loading dependency *.exe -> msvcrt.dll.
      Loading dependency *.exe -> SHELL32.dll.
      Loading dependency SHELL32.dll -> USER32.dll.
      Loading dependency USER32.dll -> win32u.dll.
      Loading dependency *.exe -> WINMM.dll.
      Loading dependency WINMM.dll -> WINMMBASE.dll.
      Loading dependency *.exe -> WSOCK32.dll.
      Loading dependency WSOCK32.dll -> WS2_32.dll.
      Loading dependency WS2_32.dll -> RPCRT4.dll.
      Loading dependency libstdc++-6.dll -> libwinpthread-1.dll.
      Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll.
      ```
      
      Trac tickets: #13093, #13189
      
      Reviewers: simonmar, rwbarton, austin, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D3028
      41e54b4b
    • Alan Zimmerman's avatar
  2. 25 Feb, 2017 1 commit
  3. 24 Feb, 2017 2 commits
    • Edward Z. Yang's avatar
      Record full FieldLabel in ifConFields. · 9d17028f
      Edward Z. Yang authored
      Summary:
      The previous implementation tried to be "efficient" by
      storing field names once in IfaceConDecls, and only just
      enough information for us to reconstruct the FieldLabel.
      But this came at a bit of code complexity cost.
      
      This patch undos the optimization, instead storing a full
      FieldLabel at each data constructor.  Consequently, this fixes
      bugs #12699 and #13250
      
      .
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: adamgundry, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3174
      9d17028f
    • Simon Peyton Jones's avatar
      Make exprIsConApp_maybe work better for literals strings · a6e13d50
      Simon Peyton Jones authored
      There are two things here
      
      * Use exprIsLiteral_maybe to "look through" a variable bound
        to a literal string.
      
      * Add CONLIKE to the NOINLINE pragma for unpackCString# and
        unpackCStringUtf8#
      
      See Trac #13317, Trac #10844, and
      Note [exprIsConApp_maybe on literal strings] in CoreSubst
      
      I did a nofib run and got essentially zero change except for one
      2.2% improvement in allocation for 'pretty'.
      a6e13d50
  4. 23 Feb, 2017 6 commits
  5. 22 Feb, 2017 6 commits
  6. 21 Feb, 2017 6 commits
    • Simon Peyton Jones's avatar
      Test Trac #13300 · 499a15db
      Simon Peyton Jones authored
      499a15db
    • Simon Peyton Jones's avatar
      Gather constraints locally in checkMain · 3c62b1d6
      Simon Peyton Jones authored
      Wiwth -fdefer-type-errors we were generating some top-level
      equality constraints, just in a corner of checkMain.  The
      fix is easy.
      
      Fixes Trac #13292
      3c62b1d6
    • Simon Peyton Jones's avatar
      Disallow class instances for synonyms · c7508083
      Simon Peyton Jones authored
      See Trac #13267 and Note [Instances and constraint synonyms]
      in TcValidity.
      
      We can't easily do a perfect job, because the rename is really trying
      to do its lookup too early.  But this is at least an improvement.
      c7508083
    • Ben Gamari's avatar
      testsuite: Fix allocations of T10547 · 82694e67
      Ben Gamari authored
      Previously the comment was correct, but the expected value itself was never
      updated.
      82694e67
    • Simon Peyton Jones's avatar
      Fix computation of dfun_tvs in mkNewTypeEqn · 713ebd7c
      Simon Peyton Jones authored
      This bug was causing Trac #13297.
      
      We were recomputing ds_tvs, and doing it wrongly (by omitting
      variables that appear only in mtheta).  But actually plain 'tvs'
      is just fine.  So code deleted, and bug fixed.
      713ebd7c
    • Simon Peyton Jones's avatar
      Fix DeriveAnyClass (again) · fd841f87
      Simon Peyton Jones authored
      This patch fixes Trac #13272.  The general approach was fine, but
      we were simply not generating the correct implication constraint
      (in particular generating fresh unification variables).  I added
      a lot more commentary to Note [Gathering and simplifying
      constraints for DeriveAnyClass]
      
      I'm still not very happy with the overall architecture.  It feels
      more complicate than it should.
      fd841f87
  7. 20 Feb, 2017 5 commits
  8. 19 Feb, 2017 1 commit
  9. 18 Feb, 2017 4 commits
    • Ben Gamari's avatar
      Disable Typeable binding generation for unboxed sums · 42ff5d97
      Ben Gamari authored
      These things are simply too expensive to generate at the moment. More
      work is needed here; see #13276 and #13261.
      42ff5d97
    • Ben Gamari's avatar
      Type-indexed Typeable · 8fa4bf9a
      Ben Gamari authored
      This at long last realizes the ideas for type-indexed Typeable discussed in A
      Reflection on Types (#11011). The general sketch of the project is described on
      the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
      index to `TypeRep`,
      
          data TypeRep (a :: k)
      
      This index allows the typechecker to reason about the type represented by the `TypeRep`.
      This index representation mechanism is exposed as `Type.Reflection`, which also provides
      a number of patterns for inspecting `TypeRep`s,
      
      ```lang=haskell
      pattern TRFun :: forall k (fun :: k). ()
                    => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                              (arg :: TYPE r1) (res :: TYPE r2).
                       (k ~ Type, fun ~~ (arg -> res))
                    => TypeRep arg
                    -> TypeRep res
                    -> TypeRep fun
      
      pattern TRApp :: forall k2 (t :: k2). ()
                    => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
                    => TypeRep a -> TypeRep b -> TypeRep t
      
      -- | Pattern match on a type constructor.
      pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a
      
      -- | Pattern match on a type constructor including its instantiated kind
      -- variables.
      pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
      ```
      
      In addition, we give the user access to the kind of a `TypeRep` (#10343),
      
          typeRepKind :: TypeRep (a :: k) -> TypeRep k
      
      Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
      newly levity polymorphic (->) type constructor.
      
      Library changes
      ---------------
      
      The primary change here is the introduction of a Type.Reflection module to base.
      This module provides access to the new type-indexed TypeRep introduced in this
      patch. We also continue to provide the unindexed Data.Typeable interface, which
      is simply a type synonym for the existentially quantified SomeTypeRep,
      
          data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep
      
      Naturally, this change also touched Data.Dynamic, which can now export the
      Dynamic data constructor. Moreover, I removed a blanket reexport of
      Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
      now).
      
      We also add a kind heterogeneous type equality type, (:~~:), to
      Data.Type.Equality.
      
      Implementation
      --------------
      
      The implementation strategy is described in Note [Grand plan for Typeable] in
      TcTypeable. None of it was difficult, but it did exercise a number of parts of
      the new levity polymorphism story which had not yet been exercised, which took
      some sorting out.
      
      The rough idea is that we augment the TyCon produced for each type constructor
      with information about the constructor's kind (which we call a KindRep). This
      allows us to reconstruct the monomorphic result kind of an particular
      instantiation of a type constructor given its kind arguments.
      
      Unfortunately all of this takes a fair amount of work to generate and send
      through the compilation pipeline. In particular, the KindReps can unfortunately
      get quite large. Moreover, the simplifier will float out various pieces of them,
      resulting in numerous top-level bindings. Consequently we mark the KindRep
      bindings as noinline, ensuring that the float-outs don't make it into the
      interface file. This is important since there is generally little benefit to
      inlining KindReps and they would otherwise strongly affect compiler performance.
      
      Performance
      -----------
      
      Initially I was hoping to also clear up the remaining holes in Typeable's
      coverage by adding support for both unboxed tuples (#12409) and unboxed sums
      (#13276). While the former was fairly straightforward, the latter ended up being
      quite difficult: while the implementation can support them easily, enabling this
      support causes thousands of Typeable bindings to be emitted to the GHC.Types as
      each arity-N sum tycon brings with it N promoted datacons, each of which has a
      KindRep whose size which itself scales with N. Doing this was simply too
      expensive to be practical; consequently I've disabled support for the time
      being.
      
      Even after disabling sums this change regresses compiler performance far more
      than I would like. In particular there are several testcases in the testsuite
      which consist mostly of types which regress by over 30% in compiler allocations.
      These include (considering the "bytes allocated" metric),
      
       * T1969:  +10%
       * T10858: +23%
       * T3294:  +19%
       * T5631:  +41%
       * T6048:  +23%
       * T9675:  +20%
       * T9872a: +5.2%
       * T9872d: +12%
       * T9233:  +10%
       * T10370: +34%
       * T12425: +30%
       * T12234: +16%
       * 13035:  +17%
       * T4029:  +6.1%
      
      I've spent quite some time chasing down the source of this regression and while
      I was able to make som improvements, I think this approach of generating
      Typeable bindings at time of type definition is doomed to give us unnecessarily
      large compile-time overhead.
      
      In the future I think we should consider moving some of all of the Typeable
      binding generation logic back to the solver (where it was prior to
      91c6b1f5). I've opened #13261 documenting this
      proposal.
      8fa4bf9a
    • Ben Gamari's avatar
      Generalize kind of the (->) tycon · b207b536
      Ben Gamari authored
      This is generalizes the kind of `(->)`, as discussed in #11714.
      
      This involves a few things,
      
       * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
      binders,
        ```lang=haskell
      (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                     (a :: TYPE r1) (b :: TYPE r2).
              a -> b -> *
        ```
      
       * Unsaturated applications of `(->)` are expressed as explicit
      `TyConApp`s
      
       * Saturated applications of `(->)` are expressed as `FunTy` as they are
      currently
      
       * Saturated applications of `(->)` are expressed by a new `FunCo`
      constructor in coercions
      
       * `splitTyConApp` needs to ensure that `FunTy`s are split to a
      `TyConApp`
         of `(->)` with the appropriate `RuntimeRep` arguments
      
       * Teach CoreLint to check that all saturated applications of `(->)` are
      represented with `FunTy`
      
      At the moment I assume that `Constraint ~ *`, which is an annoying
      source of complexity. This will
      be simplified once D3023 is resolved.
      
      Also, this introduces two known regressions,
      
      `tcfail181`, `T10403`
      =====================
      Only shows the instance,
      
          instance Monad ((->) r) -- Defined in ‘GHC.Base’
      
      in its error message when -fprint-potential-instances is used. This is
      because its instance head now mentions 'LiftedRep which is not in scope.
      I'm not entirely sure of the right way to fix this so I'm just accepting
      the new output for now.
      
      T5963 (Typeable)
      ================
      
      T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
      fingerprint without the RuntimeRep variables that (->) expects. This
      will be fixed with the merge of D2010.
      
      Haddock performance
      ===================
      
      The `haddock.base` and `haddock.Cabal` tests regress in allocations by
      about 20%. This certainly hurts, but it's also not entirely unexpected:
      the size of every function type grows with this patch and Haddock has a
      lot of functions in its heap.
      b207b536
    • Edward Z. Yang's avatar