1. 02 Dec, 2019 1 commit
  2. 28 Nov, 2019 1 commit
  3. 26 Jun, 2019 1 commit
    • Oleg Grenrus's avatar
      Add -Winferred-safe-imports warning · a863c44f
      Oleg Grenrus authored
      This commit partly reverts e69619e9
      commit by reintroducing Sf_SafeInferred SafeHaskellMode.
      
      We preserve whether module was declared or inferred Safe.  When
      declared-Safe module imports inferred-Safe, we warn.  This inferred
      status is volatile, often enough it's a happy coincidence, something
      which cannot be relied upon. However, explicitly Safe or Trustworthy
      packages won't accidentally become Unsafe.
      
      Updates haddock submodule.
      a863c44f
  4. 21 Jun, 2019 1 commit
    • Ben Gamari's avatar
      testsuite: Add stderr output for UnsafeInfered02 on Windows · 2eedb120
      Ben Gamari authored
      This test uses TemplateHaskell causing GHC to build dynamic objects on
      platforms where dynamic linking is available. However, Windows doesn't support
      dynamic linking. Consequently the test would fail on Windows with:
      
      ```patch
      --- safeHaskell/safeInfered/UnsafeInfered02.run/UnsafeInfered02.stderr.normalised	2019-06-04 15:10:10.521594200 +0000
      +++ safeHaskell/safeInfered/UnsafeInfered02.run/UnsafeInfered02.comp.stderr.normalised	2019-06-04 15:10:10.523546200 +0000
      @@ -1,5 +1,5 @@
      -[1 of 2] Compiling UnsafeInfered02_A ( UnsafeInfered02_A.hs, UnsafeInfered02_A.o, UnsafeInfered02_A.dyn_o )
      -[2 of 2] Compiling UnsafeInfered02  ( UnsafeInfered02.hs, UnsafeInfered02.o, UnsafeInfered02.dyn_o )
      +[1 of 2] Compiling UnsafeInfered02_A ( UnsafeInfered02_A.hs, UnsafeInfered02_A.o )
      +[2 of 2] Compiling UnsafeInfered02  ( UnsafeInfered02.hs, UnsafeInfered02.o )
      
       UnsafeInfered02.hs:4:1:
           UnsafeInfered02_A: Can't be safely imported!
      ```
      
      The other approach I considered for this issue is to pass `-v0` to GHC.
      However, I felt we should probably do this consistently for all of the tests in
      this directory and this would take more time than I currently have.
      2eedb120
  5. 18 Jun, 2019 1 commit
  6. 14 Jun, 2019 1 commit
    • Andrew Martin's avatar
      Implement the -XUnliftedNewtypes extension. · effdd948
      Andrew Martin authored
      GHC Proposal: 0013-unlifted-newtypes.rst
      Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
      Issues: #15219, #1311, #13595, #15883
      Implementation Details:
        Note [Implementation of UnliftedNewtypes]
        Note [Unifying data family kinds]
        Note [Compulsory newtype unfolding]
      
      This patch introduces the -XUnliftedNewtypes extension. When this
      extension is enabled, GHC drops the restriction that the field in
      a newtype must be of kind (TYPE 'LiftedRep). This allows types
      like Int# and ByteArray# to be used in a newtype. Additionally,
      coerce is made levity-polymorphic so that it can be used with
      newtypes over unlifted types.
      
      The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
      getInitialKind is more liberal, introducing a unification variable to
      return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
      When kind-checking a data constructor with kcConDecl, we attempt to
      unify the kind of a newtype with the kind of its field's type. When
      typechecking a data declaration with tcTyClDecl, we again perform a
      unification. See the implementation note for more on this.
      Co-authored-by: Richard Eisenberg's avatarRichard Eisenberg <rae@richarde.dev>
      effdd948
  7. 16 Apr, 2019 1 commit
    • Dmitry Dolgov's avatar
      Show dynamic object files (#16062) · 57eb5bc6
      Dmitry Dolgov authored
      Closes #16062. When -dynamic-too is specified, reflect that in the
      progress message, like:
      
      $ ghc Main.hs -dynamic-too
      [1 of 1] Compiling Lib              ( Main.hs, Main.o, Main.dyn_o )
      
      instead of:
      
      $ ghc Main.hs -dynamic-too
      [1 of 1] Compiling Lib              ( Main.hs, Main.o )
      57eb5bc6
  8. 01 Apr, 2019 1 commit
  9. 22 Mar, 2019 1 commit
  10. 11 Mar, 2019 1 commit
    • Alec Theriault's avatar
      Ignore more version numbers in the testsuite · bcb6769c
      Alec Theriault authored
      Prevents some tests from failing just due to mismatched version numbers.
      
      These version numbers shouldn't cause tests to fail, especially since
      we *expect* them to be regularly incremented. The motivation for this
      particular set of changes came from the changes that came along with
      the `base` version bump in 8f19ecc9.
      bcb6769c
  11. 30 Jan, 2019 3 commits
  12. 28 Jan, 2019 1 commit
  13. 15 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Control validity-checking of type synonym applications more carefully · 9dc56b61
      Ryan Scott authored
      Trac #16059 shows that when validity checking applications of type
      synonyms, GHC sometimes wasn't checking the expanded type enough.
      We must be careful, however, since checking both the expanded type as
      well as the arguments to the type synonym can lead to exponential
      blowup (see https://ghc.haskell.org/trac/ghc/ticket/16059#comment:4).
      Nor can we omit checking either the expanded type or the argument for
      correctness reasons.
      
      The solution here is to introduce a new `ExpandMode` data type that
      is plumbed through all of the type-validity-checking functions in
      `TcValidity`. `ExpandMode` dictates whether we only check the
      expanded type (`Expand`), only check the arguments (`NoExpand), or
      both (`Both`). Importantly, if we check `Both` in the function for
      validity checking type synonym applications, then we switch to
      `NoExpand` when checking the arguments so as to avoid exponential
      blowup. See `Note [Correctness and performance of type synonym validity
      checking]` for the full story.
      9dc56b61
  14. 25 Dec, 2018 1 commit
    • Ben Gamari's avatar
      testsuite: Fix a variety of issues when building with integer-simple · 99378207
      Ben Gamari authored
       * Mark arith011 as broken with integer-simple
      
         As noted in #16091, arith011 fails when run against integer-simple with a
         "divide by zero" exception. This suggests that integer-gmp and integer-simple
         are handling division by zero differently.
      
       * This also fixes broken_without_gmp; the lack of types made the previous
         failure silent, sadly. Improves situation of #16043.
      
       * Mark several tests implicitly depending upon integer-gmp as broken
         with integer-simple. These expect to see Core coming from integer-gmp,
         which breaks with integer-simple.
      
       * Increase runtime timeout multiplier of T11627a with integer-simple
      
         I previously saw that T11627a timed out in all profiling ways when run against
         integer-simple. I suspect this is due to integer-simple's rather verbose heap
         representation. Let's see whether increasing the runtime timeout helps.
      
         Fixes test for #11627.
      
      This is all in service of fixing #16043.
      99378207
  15. 13 Dec, 2018 1 commit
  16. 08 Dec, 2018 1 commit
  17. 16 Sep, 2018 1 commit
  18. 11 Aug, 2018 1 commit
    • Krzysztof Gogolewski's avatar
      Simplify testsuite driver · f27d7145
      Krzysztof Gogolewski authored
      Summary:
      - remove clean_cmd
      - framework_failures was undefined
      - times_file was not used
      - if_verbose_dump was called only when verbose >= 1; remove the check
      - simplify normalise_whitespace
      
      Test Plan: validate
      
      Reviewers: bgamari, thomie
      
      Reviewed By: thomie
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5061
      f27d7145
  19. 15 Jul, 2018 1 commit
  20. 03 Jun, 2018 1 commit
    • Tobias Dammers's avatar
      Handle abi-depends correctly in ghc-pkg · 1626fe60
      Tobias Dammers authored
      When inferring the correct abi-depends, we now look at all the package
      databases in the stack, up to and including the current one, because
      these are the ones that the current package can legally depend on. While
      doing so, we will issue warnings:
      
      - In verbose mode, we warn about every package that declares
        abi-depends:, whether we actually end up overriding them with the
        inferred ones or not ("possibly broken abi-depends").
      
      - Otherwise, we only warn about packages whose declared abi-depends
        does not match what we inferred ("definitely broken abi-depends").
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14381
      
      Differential Revision: https://phabricator.haskell.org/D4729
      1626fe60
  21. 22 May, 2018 1 commit
  22. 21 May, 2018 1 commit
  23. 19 Apr, 2018 1 commit
  24. 13 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0 · c4814ab6
      Ryan Scott authored
      This takes care of bumping the `base` and `integer-gmp`
      minor version numbers in anticipation of a GHC 8.4.2 release.
      
      While I was in town, I also filled in a `@since TODO` Haddock
      annotation for `powModSecInteger` in `integer-gmp` with
      `1.0.2.0`, and updated the changelog accordingly.
      
      Test Plan: ./validate
      
      Reviewers: hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15025
      
      Differential Revision: https://phabricator.haskell.org/D4586
      c4814ab6
  25. 15 Jan, 2018 1 commit
    • David Feuer's avatar
      Kill off irrefutable pattern errors · 492e6044
      David Feuer authored
      Distinguishing between "refutable" and "irrefutable" patterns
      (as described by the Haskell Report) in incomplete pattern errors
      was more confusing than helpful. Remove references to irrefutable
      patterns.
      
      Reviewers: hvr, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14569
      
      Differential Revision: https://phabricator.haskell.org/D4261
      492e6044
  26. 21 Sep, 2017 1 commit
  27. 11 Jul, 2017 1 commit
    • Ömer Sinan Ağacan's avatar
      Mention which -Werror promoted a warning to an error · 4befb415
      Ömer Sinan Ağacan authored
      Previously -Werror or -Werror=flag printed warnings as usual and then
      printed
      these two lines:
      
          <no location info>: error:
          Failing due to -Werror.
      
      This is not ideal: first, it's not clear which flag made one of the
      warnings an
      error. Second, warning messages are not modified in any way, so there's
      no way
      to know which warnings caused this error.
      
      With this patch we (1) promote warning messages to error messages if a
      relevant
      -Werror is enabled (2) mention which -Werror is used during this
      promotion.
      
      Previously:
      
          [1 of 1] Compiling Main             ( test.hs, test.o )
      
          test.hs:9:10: warning: [-Wincomplete-patterns]
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
            |
          9 | sInt s = case s of
            |          ^^^^^^^^^...
      
          test.hs:12:14: warning: [-Wmissing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
      1}’
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
             |
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
      
          <no location info>: error:
          Failing due to -Werror.
      
      Now:
      
          [1 of 1] Compiling Main             ( test.hs, test.o )
      
          test.hs:9:10: error: [-Wincomplete-patterns,
      -Werror=incomplete-patterns]
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
            |
          9 | sInt s = case s of
            |          ^^^^^^^^^...
      
          test.hs:12:14: error: [-Wmissing-fields, -Werror=missing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
      1}’
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
             |
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
      
      Test Plan: - Update old tests, add new tests if there aren't any
      relevant tests
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3709
      4befb415
  28. 12 Jun, 2017 1 commit
  29. 14 Mar, 2017 1 commit
  30. 26 Feb, 2017 1 commit
    • 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
  31. 18 Feb, 2017 1 commit
    • 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
  32. 23 Jan, 2017 1 commit
  33. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      The `clean_cmd` and `extra_clean` setup functions don't do anything.
      Remove them from .T files.
      
      Created using https://github.com/thomie/refactor-ghc-testsuite. This
      diff is a test for the .T-file parser/processor/pretty-printer in that
      repository.
      
          find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
      
      Tests containing inline comments or multiline strings are not modified.
      
      Preparation for #12223.
      
      Test Plan: Harbormaster
      
      Reviewers: austin, hvr, simonmar, mpickering, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3000
      
      GHC Trac Issues: #12223
      5d38fb69
  34. 18 Jan, 2017 1 commit
  35. 12 Jan, 2017 1 commit
  36. 07 Jan, 2017 1 commit
  37. 15 Dec, 2016 1 commit
  38. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Summary:
      Add prettyprinter tests, which take a file, parse it, pretty print it,
      re-parse the pretty printed version and then compare the original and
      new ASTs (ignoring locations)
      
      Updates haddock submodule to match the AST changes.
      
      There are three issues outstanding
      
      1. Extra parens around a context are not reproduced. This will require an
         AST change and will be done in a separate patch.
      
      2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
         to prevent noise in the output.
      
         I am not sure what the desired behaviour in this case is, so have left
         it as before. Test Ppr047 is marked as expected fail for this.
      
      3. Apart from in a context, the ParsedSource AST keeps all the parens from
         the original source.  Something is happening in the renamer to remove the
         parens around visible type application, causing T12530 to fail, as the
         dumped splice decl is after the renamer.
      
         This needs to be fixed by keeping the parens, but I do not know where they
         are being removed.  I have amended the test to pass, by removing the parens
         in the expected output.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, mpickering, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2752
      
      GHC Trac Issues: #3384
      499e4382