1. 22 Nov, 2018 6 commits
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
      
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
      
         Fix unused-import stuff in a better way
      
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      
      This led to Trac #13064 and #15393
      
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      
      The two important changes are
      
      * Fix the bug in bestImport
      
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      
      In unravalling this I also ended up doing a few other things
      
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      
      * Delete dead code RdrName.greUsedRdrName
      
      Bumps a few submodules.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5312
      6353efc7
    • Ryan Scott's avatar
      Overhaul -fprint-explicit-kinds to use VKA · f5d20838
      Ryan Scott authored
      This patch changes the behavior of `-fprint-explicit-kinds`
      so that it displays kind argument using visible kind application.
      In other words, the flag now:
      
      1. Prints instantiations of specified variables with `@(...)`.
      2. Prints instantiations of inferred variables with `@{...}`.
      
      In addition, this patch removes the `Use -fprint-explicit-kinds to
      see the kind arguments` error message that often arises when a type
      mismatch occurs due to different kinds. Instead, whenever there is a
      kind mismatch, we now enable the `-fprint-explicit-kinds` flag
      locally to help cue to the programmer where the error lies.
      (See `Note [Kind arguments in error messages]` in `TcErrors`.)
      As a result, these funny `@{...}` things can now appear to the user
      even without turning on the `-fprint-explicit-kinds` flag explicitly,
      so I took the liberty of documenting them in the users' guide.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15871
      
      Differential Revision: https://phabricator.haskell.org/D5314
      f5d20838
    • Ryan Scott's avatar
      Fix #15852 by eta expanding data family instance RHSes, too · 014d6c1f
      Ryan Scott authored
      When I defined `etaExpandFamInstLHS`, I blatantly forgot
      to eta expand the RHSes of data family instances. (Actually, I
      claimed that they didn't //need// to be eta expanded. I'm not sure
      what I was thinking.)
      
      This fixes the issue by changing `etaExpandFamInstLHS` to
      `etaExpandFamInst` and, well, making it actually eta expand the RHS.
      
      Test Plan: make test TEST=T15852
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15852
      
      Differential Revision: https://phabricator.haskell.org/D5328
      014d6c1f
    • Simon Jakobi's avatar
      Refactor TcRnMonad.mapAndRecoverM · 66f0056a
      Simon Jakobi authored
      This version doesn't require the 'reverse' step after the monadic
      fold.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: monoidal, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5343
      66f0056a
    • Simon Jakobi's avatar
      Don't reverse explicit export lists during renaming · 7cba71fc
      Simon Jakobi authored
      This will be useful for Hi Haddock / D5067.
      
      Previously any export list in 'tcg_rn_exports' would be in reverse
      order.
      
      Also remove a redundant setSrcSpan.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5347
      7cba71fc
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4881
      13bb4bf4
  2. 17 Nov, 2018 3 commits
  3. 15 Nov, 2018 1 commit
  4. 11 Nov, 2018 1 commit
  5. 08 Nov, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15845 by defining etaExpandFamInstLHS and using it · 63a81707
      Ryan Scott authored
      Summary:
      Both #9692 and #14179 were caused by GHC being careless
      about using eta-reduced data family instance axioms. Each of those
      tickets were fixed by manually whipping up some code to eta-expand
      the axioms. The same sort of issue has now caused #15845, so I
      figured it was high time to factor out the code that each of these
      fixes have in common.
      
      This patch introduces the `etaExpandFamInstLHS` function, which takes
      a family instance's type variables, LHS types, and RHS type, and
      returns type variables and LHS types that have been eta-expanded if
      necessary, in the case of a data family instance. (If it's a type
      family instance, `etaExpandFamInstLHS` just returns the supplied type
      variables and LHS types unchanged).
      
      Along the way, I noticed that many references to
      `Note [Eta reduction for data families]` (in `FamInstEnv`) had
      slightly bitrotted (they either referred to a somewhat different
      name, or claimed that the Note lived in a different module), so
      I took the liberty of cleaning those up.
      
      Test Plan: make test TEST="T9692 T15845"
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15845
      
      Differential Revision: https://phabricator.haskell.org/D5294
      63a81707
  6. 05 Nov, 2018 1 commit
  7. 04 Nov, 2018 1 commit
    • Roland Senn's avatar
      Fix for Trac #15611: Scope errors lie about what modules are imported. · 1a3b9bd0
      Roland Senn authored
      Summary:
      For the error message:
          Not in scope X.Y
          Module X does not export Y
          No module named ‘X’ is imported:
      there are 2 cases, where we don't show the last "no module named is imported" line:
      1. If the module X has been imported.
      2. If the module X is the current module. There are 2 subcases:
      
         2.1 If the unknown module name is in a input source file,
             then we can use the getModule function to get the current module name.
      
         2.2 If the unknown module name has been entered by the user in GHCi,
             then the getModule function returns something like "interactive:Ghci1",
             and we have to check the current module in the last added entry of
             the HomePackageTable.
      
      Test Plan: make test TESTS="T15611a T15611b"
      
      Reviewers: monoidal, hvr, thomie, dfeuer, bgamari, DavidEichmann
      
      Reviewed By: monoidal, DavidEichmann
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15611
      
      Differential Revision: https://phabricator.haskell.org/D5284
      1a3b9bd0
  8. 02 Nov, 2018 1 commit
    • Michal Terepeta's avatar
      Add Int8# and Word8# · 2c959a18
      Michal Terepeta authored
      This is the first step of implementing:
      https://github.com/ghc-proposals/ghc-proposals/pull/74
      
      The main highlights/changes:
      
          primops.txt.pp gets two new sections for two new primitive types for
          signed and unsigned 8-bit integers (Int8# and Word8 respectively) along
          with basic arithmetic and comparison operations. PrimRep/RuntimeRep get
          two new constructors for them. All of the primops translate into the
          existing MachOPs.
      
          For CmmCalls the codegen will now zero-extend the values at call
          site (so that they can be moved to the right register) and then truncate
          them back their original width.
      
          x86 native codegen needed some updates, since it wasn't able to deal
          with the new widths, but all the changes are quite localized. LLVM
          backend seems to just work.
      
      This is the second attempt at merging this, after the first attempt in
      D4475 had to be backed out due to regressions on i386.
      
      Bumps binary submodule.
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      
      Test Plan: ./validate (on both x86-{32,64})
      
      Reviewers: bgamari, hvr, goldfire, simonmar
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5258
      2c959a18
  9. 01 Nov, 2018 3 commits
    • Matthías Páll Gissurarson's avatar
      Add built-in syntax suggestions, and refactor to allow library use · 1c92f193
      Matthías Páll Gissurarson authored
      Summary:
      This change to the valid hole fits adds built-in syntax candidates (like (:) and []),
      so that they are checked in addition to what is in scope.
      
      The rest is merely a refactor and export of the functions used to find the valid
      hole fits, since there was interest at ICFP to use the valid hole fit machinery for
      additional uses. By exporting the `tcFilterHoleFits` function, this can now be done
      without having to rely on parsing the actual error message.
      
      Test Plan: Test for built-in syntax included
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5227
      1c92f193
    • Richard Eisenberg's avatar
      Don't lint erroneous programs. · 1f72a1c8
      Richard Eisenberg authored
      newFamInst lints its types. This is good. But it's not so good
      when there have been errors and thus recovery tycons are about.
      So we now don't.
      
      Fixes #15796.
      
      Test case: typecheck/should_fail/T15796
      1f72a1c8
    • Richard Eisenberg's avatar
      Actually fail in failIfEmitsConstraints · 74ed9c1c
      Richard Eisenberg authored
      The function TcHsType.failIfEmitsConstraints says that it fails.
      It even does so in its name. But it didn't! It *reported* constraints
      but didn't fail. Now it does.
      
      This is important in tcHsClsInstType; see the comments therein.
      
      This was discovered while looking at #15797, but that ticket
      requires visible kind application to exhibit the bug; the test
      case will come with the patch for #12045.
      74ed9c1c
  10. 29 Oct, 2018 4 commits
    • Richard Eisenberg's avatar
      Revert "Remove kind generalisation from tcRnType" · 09740d50
      Richard Eisenberg authored
      This reverts commit 3a51abd0.
      
      I had hit the wrong button when trying to validate the original
      commit... and ended up committing it prematurely instead.
      This reversion commit
      also updates the comments to explain why we kind-generalise.
      09740d50
    • Richard Eisenberg's avatar
      Remove kind generalisation from tcRnType · 3a51abd0
      Richard Eisenberg authored
      There is no need to kind-generalise in tcRnType. Types are not
      instantiated eagerly, so there's never anything to generalise.
      3a51abd0
    • Richard Eisenberg's avatar
      Fix #15787 by squashing a coercion hole. · 4427315a
      Richard Eisenberg authored
      In type-incorrect code, we can sometimes let a coercion
      hole make it through the zonker. If this coercion hole then
      ends up in the environment (e.g., in the type of a data
      constructor), then it causes trouble later.
      
      This patch avoids trouble by substituting the coercion hole
      for its representative CoVar. Really, any coercion would do,
      but the CoVar was very handy.
      
      test case: polykinds/T15787
      4427315a
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      
      As a bonus, we now have more control over the ordering of such
      skolems.
      
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      
      Test cases: dependent/should_fail/T14880{,-2},
                  dependent/should_fail/T15743[cd]
                  dependent/should_compile/T15743{,e}
                  ghci/scripts/T15743b
                  polykinds/T15592
                  dependent/should_fail/T15591[bc]
                  ghci/scripts/T15591
      5e45ad10
  11. 28 Oct, 2018 3 commits
    • Ben Gamari's avatar
      Plugins: Add documentation and missing exports · 49f5c6c3
      Ben Gamari authored
      Summary:
      Previously the TcPlugin and CorePlugin type synonyms were not exporting,
      resulting in much confusion.
      
      Reviewers: mpickering
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5237
      49f5c6c3
    • Ningning Xie's avatar
      Fix TcType.anyRewritableTyVar · a7f64c6c
      Ningning Xie authored
      Summary:
      This patch fixes #15805, where we found that
      `TcType.anyRewritableTyVar` has one wrong case.
      
      Besides the fix, it also:
      - removed some unnecessary `ASSERT2(tcIsTcTyVar...)` in `TcType`, as now we have
           `tcIsTcTyVar = isTyVar`.
      - fixed some comments
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15805
      
      Differential Revision: https://phabricator.haskell.org/D5263
      a7f64c6c
    • Ningning Xie's avatar
      Fix `:k` command: add validity checking · c4a876d5
      Ningning Xie authored
      Summary:
      This patch fixes #15806, where we found that the `:k` command in GHCi
      misses a validity checking for the type.
      
      Missing validity checking causes `:k` to accept types that are not validated.
      For example, `:k (Maybe (forall a. a -> a))` (incorrectly) returns `*`, while
      impredictivity of type instantiation shouldn't be allowed.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15806
      
      Differential Revision: https://phabricator.haskell.org/D5265
      c4a876d5
  12. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      
      This modifies the Template Haskell AST -- old code may break!
      
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      
      Includes submodule update for Haddock.
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, alanz
      
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      
      GHC Trac Issues: #2600, #14268
      
      Differential Revision: https://phabricator.haskell.org/D4894
      512eeb9b
  13. 26 Oct, 2018 3 commits
    • Simon Jakobi's avatar
      Remove redundant SOURCE import · 23956b2a
      Simon Jakobi authored
      23956b2a
    • Simon Peyton Jones's avatar
      Fix generalisation for type constructors · 4de4b225
      Simon Peyton Jones authored
      Fixing the way that we close-over-kinds when taking the
      free vars of a type revealed that the way we generalise
      type constructors was a bit wrong.
      
      This fixes it.  See TcTyClDecls
      Note [Generalisation for type constructors]
      4de4b225
    • Simon Peyton Jones's avatar
      De-monadise the 'extract' functions in RnTypes · e6bf96c9
      Simon Peyton Jones authored
      As Trac #15765 says, Once upon a time, the extract functions
      at the bottom of RnTypes were pure. Then, along came -XTypeInType,
      which needed to do a check in these functions for users mixing
      type variables with kind variables.
      
      Now, however, with -XTypeInType gone again, we no longer
      do this check. Thus, there is no reason to keep these
      functions monadic.
      e6bf96c9
  14. 25 Oct, 2018 4 commits
  15. 24 Oct, 2018 7 commits
    • Simon Peyton Jones's avatar
      Remove unnecessary free-var-set deletion · 9aaa8971
      Simon Peyton Jones authored
      In TcSimplify.neededEvVars, in add_implic_seeds we were
      deleting the 'givens'; but they are already deleted, so
      this is a no-op.  This patch just remove the redundant
      delete.
      9aaa8971
    • Simon Peyton Jones's avatar
      Wibble report a wanted · ecfe38ef
      Simon Peyton Jones authored
      ecfe38ef
    • Simon Peyton Jones's avatar
      Add HasDebugCallStack to ctEvCoecion · e2ca1072
      Simon Peyton Jones authored
      This is a debug-only change
      e2ca1072
    • Simon Peyton Jones's avatar
      Report a Wanted error even if there are Given ones · 6b1102e2
      Simon Peyton Jones authored
      We suppress some Given errors; see Note [Given errors]
      in TcErrors.  But we must be careful not to suppress
      Wanted errors because of the presence of these Given
      errors -- else we might allow compilation to bogusly
      proceed
      
      The rubber hits the road in TcRnTypes.insolubleCt,
      where we don't want to treat Givens as insoluble,
      nor (and this is the new bit) Deriveds that arise
      from Givens.  See Note [Given insolubles] in TcRnTypes.
      
      This fixes #15767.
      6b1102e2
    • Simon Peyton Jones's avatar
      Don't print out undefined coercions · 7d903644
      Simon Peyton Jones authored
      A debug-print was trying to print the coercion returned
      by the flattener.  But that coercion can be undefined
      in the case of Derived constraints.  Because we might
      rewrite it with [D] a ~ ty, and there is no evidence
      for that.
      
      Solution: don't attempt to print the coercion.
      7d903644
    • Simon Peyton Jones's avatar
      Solve equalities in a pattern signature · 7ea714cd
      Simon Peyton Jones authored
      Trac #15694 showed that we were forgetting to solve
      the equalities of a pattern signature until too late.
      
      Result: WARNINGs and a panic:
        "Type-correct unfilled coercion hole"
      7ea714cd
    • Simon Peyton Jones's avatar
      Refactor the treatment of predicate types · 0faf7fd3
      Simon Peyton Jones authored
      Trac #15648 showed that GHC was a bit confused about the
      difference between the types for
      
      * Predicates
      * Coercions
      * Evidence (in the typechecker constraint solver)
      
      This patch cleans it up. See especially Type.hs
      Note [Types for coercions, predicates, and evidence]
      
      Particular changes
      
      * Coercion types (a ~# b) and (a ~#R b) are not predicate types
        (so isPredTy reports False for them) and are not implicitly
        instantiated by the type checker.  This is a real change, but
        it consistently reflects that fact that (~#) and (~R#) really
        are different from predicates.
      
      * isCoercionType is renamed to isCoVarType
      
      * During type inference, simplifyInfer, we do /not/ want to infer
        a constraint (a ~# b), because that is no longer a predicate type.
        So we 'lift' it to (a ~ b). See TcType
        Note [Lift equality constaints when quantifying]
      
      * During type inference for pattern synonyms, we need to 'lift'
        provided constraints of type (a ~# b) to (a ~ b).  See
        Note [Equality evidence in pattern synonyms] in PatSyn
      
      * But what about (forall a. Eq a => a ~# b)? Is that a
        predicate type?  No -- it does not have kind Constraint.
        Is it an evidence type?  Perhaps, but awkwardly so.
      
        In the end I decided NOT to make it an evidence type,
        and to ensure the the type inference engine never
        meets it.  This made me /simplify/ the code in
        TcCanonical.makeSuperClasses; see TcCanonical
        Note [Equality superclasses in quantified constraints]
      
        Instead I moved the special treatment for primitive
        equality to TcInteract.doTopReactOther.  See TcInteract
        Note [Looking up primitive equalities in quantified constraints]
      
        Also see Note [Evidence for quantified constraints] in Type.
      
        All this means I can have
           isEvVarType ty = isCoVarType ty || isPredTy ty
        which is nice.
      
      All in all, rather a lot of work for a small refactoring,
      but I think it's a real improvement.
      0faf7fd3