1. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  2. 20 Mar, 2019 3 commits
  3. 15 Mar, 2019 2 commits
    • Ryan Scott's avatar
      Update Trac ticket URLs to point to GitLab · 610ec224
      Ryan Scott authored
      This moves all URL references to Trac tickets to their corresponding
      GitLab counterparts.
      610ec224
    • Ryan Scott's avatar
      Remove the GHCi debugger's panicking isUnliftedType check · 8162eab2
      Ryan Scott authored
      The GHCi debugger has never been that robust in the face of
      higher-rank types, or even types that are _interally_ higher-rank,
      such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
      however, things became even worse, as the debugger would start to
      _panic_ when a user tries passing the name of a higher-rank thing
      to `:print`. This all ties back to a strange `isUnliftedType` check
      in `Debugger` that was mysteriously added 11 years ago
      (in commit 4d71f5ee) with no
      explanation whatsoever.
      
      After some experimentation, no one is quite sure what this
      `isUnliftedType` check is actually accomplishing. The test suite
      still passes if it's removed, and I am unable to observe any
      differences in debugger before even with data types that _do_ have
      fields of unlifted types (e.g., `data T = MkT Int#`). Given that
      this is actively causing problems (see #14828), the prudent thing
      to do seems to be just removing this `isUnliftedType` check, and
      waiting to see if anyone shouts about it. This patch accomplishes
      just that.
      
      Note that this patch fix the underlying issues behind #14828, as the
      debugger will still print unhelpful info if you try this:
      
      ```
      λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
      λ> :print f
      f = (_t1::t1)
      ```
      
      But fixing this will require much more work, so let's start with the
      simple stuff for now.
      8162eab2
  4. 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
  5. 08 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Use captureTopConstraints in TcRnDriver calls · 5be7ad78
      Simon Peyton Jones authored
      Trac #16376 showed the danger of failing to report an error
      that exists only in the unsolved constraints, if an exception
      is raised (via failM).
      
      Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
      did just that -- i.e. it found errors in the constraints, and
      called failM to avoid a misleading cascade.
      
      So we need to be sure to call captureTopConstraints to report
      those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
      in TcRnDriver.tcRnType.
      
      As a result the error messages from test T13466 improved slightly,
      a happy outcome.
      5be7ad78
  6. 07 Mar, 2019 3 commits
    • Ryan Scott's avatar
      Fix #16391 by using occCheckExpand in TcValidity · 068b7e98
      Ryan Scott authored
      The type-variables-escaping-their-scope-via-kinds check in
      `TcValidity` was failing to properly expand type synonyms, which led
      to #16391. This is easily fixed by using `occCheckExpand` before
      performing the validity check.
      
      Along the way, I refactored this check out into its own function,
      and sprinkled references to Notes to better explain all of the moving
      parts. Many thanks to @simonpj for the suggestions.
      
      Bumps the haddock submodule.
      068b7e98
    • Phuong Trinh's avatar
      Fix #16392: revertCAFs in external interpreter when necessary · 7a68254a
      Phuong Trinh authored
      We revert CAFs when loading/adding modules in ghci (presumably to refresh
      execution states and to allow for object code to be unloaded from the runtime).
      However, with `-fexternal-interpreter` enabled, we are only doing it in the
      ghci process instead of the external interpreter process where the cafs are
      allocated and computed. This makes sure that revertCAFs is done in the
      appropriate process no matter if that flag is present or not.
      7a68254a
    • Ben Gamari's avatar
      a65bcbe7
  7. 27 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Treat kind/type variables identically, demolish FKTV · 5bc195b1
      Vladislav Zavialov authored
      Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
      Fixes Trac #16334, Trac #16315
      
      With this patch, scoping rules for type and kind variables have been
      unified: kind variables no longer receieve special treatment. This
      simplifies both the language and the implementation.
      
      User-facing changes
      -------------------
      
      * Kind variables are no longer implicitly quantified when an explicit
        forall is used:
      
          p ::             Proxy (a :: k)    -- still accepted
          p :: forall k a. Proxy (a :: k)    -- still accepted
          p :: forall   a. Proxy (a :: k)    -- no longer accepted
      
        In other words, now we adhere to the "forall-or-nothing" rule more
        strictly.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * The -Wimplicit-kind-vars warning has been deprecated.
      
      * Kind variables are no longer implicitly quantified in constructor
        declarations:
      
          data T a        = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- no longer accepted
          data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- still accepted
      
        Related function: RnTypes.extractRdrKindSigVars
      
      * Implicitly quantified kind variables are no longer put in front of
        other variables:
      
          f :: Proxy (a :: k) -> Proxy (b :: j)
      
          f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b   -- old order
          f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b   -- new order
      
        This is a breaking change for users of TypeApplications. Note that
        we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
        See "Ordering of specified variables" in the User's Guide.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * In type synonyms and type family equations, free variables on the RHS
        are no longer implicitly quantified unless used in an outermost kind
        annotation:
      
          type T = Just (Nothing :: Maybe a)         -- no longer accepted
          type T = Just Nothing :: Maybe (Maybe a)   -- still accepted
      
        The latter form is a workaround due to temporary lack of an explicit
        quantification method. Ideally, we would write something along these
        lines:
      
          type T @a = Just (Nothing :: Maybe a)
      
        Related function: RnTypes.extractHsTyRdrTyVarsKindVars
      
      * Named wildcards in kinds are fixed (Trac #16334):
      
          x :: (Int :: _t)    -- this compiles, infers (_t ~ Type)
      
        Related function: RnTypes.partition_nwcs
      
      Implementation notes
      --------------------
      
      * One of the key changes is the removal of FKTV in RnTypes:
      
        - data FreeKiTyVars = FKTV { fktv_kis    :: [Located RdrName]
        -                          , fktv_tys    :: [Located RdrName] }
        + type FreeKiTyVars = [Located RdrName]
      
        We used to keep track of type and kind variables separately, but
        now that they are on equal footing when it comes to scoping, we
        can put them in the same list.
      
      * extract_lty and family are no longer parametrized by TypeOrKind,
        as we now do not distinguish kind variables from type variables.
      
      * PatSynExPE and the related Note [Pattern synonym existentials do not scope]
        have been removed (Trac #16315). With no implicit kind quantification,
        we can no longer trigger the error.
      
      * reportFloatingKvs and the related Note [Free-floating kind vars]
        have been removed. With no implicit kind quantification,
        we can no longer trigger the error.
      5bc195b1
  8. 25 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Fix the ghci063 test on Darwin (Trac #16201) · f320f3b2
      Vladislav Zavialov authored
      We use "touch -r" to set modification timestamps, which leads to precision loss
      on Darwin. For example,
      
         before: 2019-02-25 01:11:23.807627350 +0300
         after:  2019-02-25 01:11:23.807627000 +0300
                                           ^^^
      This means we can't trick GHCi into thinking the file hasn't been changed by
      restoring its old timestamp, as we cannot faithfully restore all digits.
      
      The solution is to nullify the insignificant digits before the first :load
      f320f3b2
  9. 24 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Expression/command ambiguity resolution · e61f6e35
      Vladislav Zavialov authored
      This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
      introducing a new ambiguity resolution system in the parser.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a command:
      
      	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
      	proc x -> do { (stuff) }        -- 'stuff' is a command
      
      Until we encounter arrow syntax (-<) we don't know whether to parse
      'stuff' as an expression or a command.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
      
      This meant polluting 'HsExpr' with command-related constructors. In
      other words, limitations of the parser were affecting the AST, and
      all other code (the renamer, the typechecker) had to deal with these
      extra constructors by panicking.
      
      We fix this abstraction leak by parsing into an intermediate
      representation, 'ExpCmd':
      
      	data ExpCmdG b where
      	  ExpG :: ExpCmdG HsExpr
      	  CmdG :: ExpCmdG HsCmd
      
      	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
      
      	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
      	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
      	checkExp f = f ExpG  -- interpret as an expression
      	checkCmd f = f CmdG  -- interpret as a command
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/command ambiguity.
      
      Future work: apply the same principles to the expression/pattern
      ambiguity.
      e61f6e35
  10. 15 Feb, 2019 1 commit
  11. 14 Feb, 2019 2 commits
    • Simon Peyton Jones's avatar
      Fail fast in solveLocalEqualities · 5c1f268e
      Simon Peyton Jones authored
      This patch makes us fail fast in TcSimplify.solveLocalEqualities,
      and in TcHsType.tc_hs_sig_type, if there are insoluble constraints.
      
      Previously we ploughed on even if there were insoluble constraints,
      leading to a cascade of hard-to-understand type errors. Failing
      eagerly is much better; hence a lot of testsuite error message
      changes.  Eg if we have
                f :: [Maybe] -> blah
                f xs = e
      then trying typecheck 'f x = e' with an utterly bogus type
      is just asking for trouble.
      
      I can't quite remember what provoked me to make this change,
      but I think the error messages are notably improved, by
      removing confusing clutter and focusing on the real error.
      5c1f268e
    • Simon Peyton Jones's avatar
      Make a smart mkAppTyM · 68278382
      Simon Peyton Jones authored
      This patch finally delivers on Trac #15952.  Specifically
      
      * Completely remove Note [The tcType invariant], along with
        its complicated consequences (IT1-IT6).
      
      * Replace Note [The well-kinded type invariant] with:
      
            Note [The Purely Kinded Type Invariant (PKTI)]
      
      * Instead, establish the (PKTI) in TcHsType.tcInferApps,
        by using a new function mkAppTyM when building a type
        application.  See Note [mkAppTyM].
      
      * As a result we can remove the delicate mkNakedXX functions
        entirely.  Specifically, mkNakedCastTy retained lots of
        extremly delicate Refl coercions which just cluttered
        everything up, and(worse) were very vulnerable to being
        silently eliminated by (say) substTy. This led to a
        succession of bug reports.
      
      The result is noticeably simpler to explain, simpler
      to code, and Richard and I are much more confident that
      it is correct.
      
      It does not actually fix any bugs, but it brings us closer.
      E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite
      do so.  However, it makes it much easier to fix.
      
      I also did a raft of other minor refactorings:
      
      * Use tcTypeKind consistently in the type checker
      
      * Rename tcInstTyBinders to tcInvisibleTyBinders,
        and refactor it a bit
      
      * Refactor tcEqType, pickyEqType, tcEqTypeVis
        Simpler, probably more efficient.
      
      * Make zonkTcType zonk TcTyCons, at least if they have
        any free unification variables -- see zonk_tc_tycon
        in TcMType.zonkTcTypeMapper.
      
        Not zonking these TcTyCons was actually a bug before.
      
      * Simplify try_to_reduce_no_cache in TcFlatten (a lot)
      
      * Combine checkExpectedKind and checkExpectedKindX.
        And then combine the invisible-binder instantation code
        Much simpler now.
      
      * Fix a little bug in TcMType.skolemiseQuantifiedTyVar.
        I'm not sure how I came across this originally.
      
      * Fix a little bug in TyCoRep.isUnliftedRuntimeRep
        (the ASSERT was over-zealous).  Again I'm not certain
        how I encountered this.
      
      * Add a missing solveLocalEqualities in
        TcHsType.tcHsPartialSigType.
        I came across this when trying to get level numbers
        right.
      68278382
  12. 12 Feb, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16299 by deleting incorrect code from IfaceSyn · 8b476d82
      Ryan Scott authored
      GHCi's `:info` command was pretty-printing Haskell98-style data types
      with explicit return kinds if the return kind wasn't `Type`. This
      leads to bizarre output like this:
      
      ```
      λ> :i (##)
      data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##)
              -- Defined in ‘GHC.Prim’
      ```
      
      Or, with unlifted newtypes:
      
      ```
      λ> newtype T = MkT Int#
      λ> :i T
      newtype T :: TYPE 'IntRep = MkT Int#
              -- Defined at <interactive>:5:1
      ```
      
      The solution is simple: just delete one part from `IfaceSyn` where
      GHC mistakenly pretty-prints the return kinds for non-GADTs.
      8b476d82
  13. 06 Feb, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16287 by checking for more unsaturated synonym arguments · c07e7ecb
      Ryan Scott authored
      Trac #16287 shows that we were checking for unsaturated type synonym
      arguments (in `:kind`) when the argument was to a type synonym, but
      _not_ when the argument was to some other form of type constructor,
      such as a data type. The solution is to use the machinery that
      rejects unsaturated type synonym arguments (previously confined to
      `check_syn_tc_app`) to `check_arg_type`, which checks these other
      forms of arguments. While I was in town, I cleaned up
      `check_syn_tc_app` a bit to only invoke `check_arg_type` so as to
      minimize the number of different code paths that that function could
      go down.
      c07e7ecb
  14. 31 Jan, 2019 2 commits
  15. 30 Jan, 2019 4 commits
    • Zejun Wu's avatar
      Allocate bss section within proper range of other sections · 740534d4
      Zejun Wu authored
      Summary:
      This re-applies {D5195} and {D5235}, they were reverted as part of diff
      stack to unbreak i386. The proper fix is done in {D5289}.
      
      Allocate bss section within proper range of other sections:
      
      * when `+RTS -xp` is passed, allocate it contiguously as we did for
        jump islands
      * when we mmap the code to lower 2Gb, we should allocate bss section
        there too
      
      Test Plan:
      1. `./validate`
      
      2.
      
      with
      
      ```
      DYNAMIC_GHC_PROGRAMS = NO
      DYNAMIC_BY_DEFAULT = NO
      ```
      
      `TEST="T15729" make test` passed in both linux (both i386 and x86_64) and macos.
      
      3.
      
      Also test in a use case where we used to encouter error like:
      
      ```
      ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) =
      b90282ba
      ```
      
      and now, everything works fine.
      
      Reviewers: simonmar, bgamari, angerman, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15729
      
      Differential Revision: https://phabricator.haskell.org/D5290
      740534d4
    • Ben Gamari's avatar
      testsuite: Use makefile_test · 513a449c
      Ben Gamari authored
      This eliminates most uses of run_command in the testsuite in favor of the more
      structured makefile_test.
      513a449c
    • Ben Gamari's avatar
      Revert "Batch merge" · 172a5933
      Ben Gamari authored
      This reverts commit 76c8fd67.
      172a5933
    • Ben Gamari's avatar
      Batch merge · 76c8fd67
      Ben Gamari authored
      76c8fd67
  16. 23 Jan, 2019 2 commits
  17. 16 Jan, 2019 2 commits
    • Alec Theriault's avatar
      Fix tests for `integer-simple` · d2eb344a
      Alec Theriault authored
      A bunch of tests for `integer-simple` were now broken for a foolish reason:
      unlike the `integer-gmp` case, there is no CorePrep optimization for turning
      small integers directly into applications of `S#`.
      
      Rather than port this optimization to `integer-simple` (which would involve
      moving a bunch of `integer-simple` names into `PrelNames`), I switched
      as many tests as possible to use `Int`.
      
      The printing of `Integer` is already tested in `print037`.
      d2eb344a
    • Roland Senn's avatar
  18. 13 Jan, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Refactor GHCi UI to fix #11606, #12091, #15721, #16096 · a34ee615
      Ömer Sinan Ağacan authored
      Instead of parsing and executing a statement or declaration directly we
      now parse them first and then execute in a separate step. This gives us
      the flexibility to inspect the parsed declaration before execution.
      Using this we now inspect parsed declarations, and if it's a single
      declaration of form `x = y` we execute it as `let x = y` instead, fixing
      a ton of problems caused by poor declaration support in GHCi.
      
      To avoid any users of the modules I left `execStmt` and `runDecls`
      unchanged and added `execStmt'` and `runDecls'` which work on parsed
      statements/declarations.
      a34ee615
  19. 08 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Be pickier about unsaturated synonyms in :kind · 6b70cf61
      Ryan Scott authored
      Summary:
      We currently permit any and all uses of unsaturated type
      synonyms and type families in GHCi's `:kind` command, which allows
      strange interactions like this one:
      
      ```
      > :set -XTypeFamilies -XPolyKinds
      > type family Id (a :: k)
      > type instance Id a = a
      > type Foo x = Maybe
      > :kind! Id Foo
      ```
      
      This is probably a stretch too far, so this patch moves to disallow
      unsaturated synonyms that aren't at the top level (we still want to
      allow `:kind Id`, for instance). We do this by augmenting `GhciCtxt`
      with an additional `Bool` field to indicate if we are at the
      outermost level of the type being passed to `:kind` or not. See
      `Note [Unsaturated type synonyms in GHCi]` in `TcValidity` for the
      full story.
      
      Test Plan: make test TEST=T16013
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: simonpj, goldfire, rwbarton, carter
      
      GHC Trac Issues: #16013
      
      Differential Revision: https://phabricator.haskell.org/D5471
      6b70cf61
  20. 03 Jan, 2019 1 commit
    • My Nguyen's avatar
      Visible kind application · 17bd1635
      My Nguyen authored
      Summary:
      This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
      It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
      written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
      application, just like in term-level.
      
      There are a few remaining issues with this patch, as documented in
      ticket #16082.
      
      Includes a submodule update for Haddock.
      
      Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
      
      Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
      
      Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
      
      GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
      
      Differential Revision: https://phabricator.haskell.org/D5229
      17bd1635
  21. 29 Dec, 2018 1 commit
  22. 19 Dec, 2018 2 commits
    • Ryan Scott's avatar
      Fix #16030 by refactoring IfaceSyn's treatment of GADT constructors · 9d9e3557
      Ryan Scott authored
      Summary:
      GHCi's `:info` command was pretty-printined GADT
      constructors suboptimally in the following ways:
      
      1. Sometimes, fields were parenthesized when they did not need it,
         e.g.,
      
      ```lang=haskell
      data Foo a where
        MkFoo :: (Maybe a) -> Foo a
      ```
      
         I fixed this by refactoring some code in `pprIfaceConDecl` to be a
         little smarter with respect to GADT syntax. See `pprFieldArgTy`
         and `pprArgTy`.
      2. With `-fprint-explicit-kinds` enabled, there would be times when
         specified arguments would be printed without a leading `@` in GADT
         return types, e.g.,
      
      ```lang=haskell
      data Bar @k (a :: k) where
        MkBar :: Bar k a
      ```
      
         It turns out that `ppr_tc_app`, the function which pretty-prints
         these return types, was not using the proper machinery to print
         out the arguments, which caused the visibilities to be forgotten
         entirely. I refactored `ppr_tc_app` to do this correctly.
      
      Test Plan: make test TEST=T16030
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #16030
      
      Differential Revision: https://phabricator.haskell.org/D5440
      9d9e3557
    • Krzysztof Gogolewski's avatar
      Use unicode arrows with -fprint-unicode-syntax · d555d4be
      Krzysztof Gogolewski authored
      Summary:
      See #8959, this is one more place where we
      can pretty-print Unicode syntax.
      
      Test Plan: validate
      
      Reviewers: nomeata, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #8959
      
      Differential Revision: https://phabricator.haskell.org/D5439
      d555d4be
  23. 18 Dec, 2018 1 commit
  24. 13 Dec, 2018 1 commit
  25. 11 Dec, 2018 2 commits
  26. 08 Dec, 2018 1 commit
    • Roland Senn's avatar
      Fix #15369: GHCi doesn't honor :set +c when loading for a second time · 57c9b1ae
      Roland Senn authored
      The decision to (re)collect the type info for a (re)loaded module is
      now taken only by comparing the file timestamps of the .hs file of the
      module. (Or form the .o file if the .hs file is missing).
      If the file timestamp changes, we (re)collect the type info.
      The timestamp of the processing time of the last collect is no longer
      used.
      
      Test Plan: make test TEST=T15369
      
      Reviewers: alanz, hvr, monoidal, osa1, thomie, bgamari, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15369
      
      Differential Revision: https://phabricator.haskell.org/D5376
      57c9b1ae