1. 29 Oct, 2018 7 commits
    • Ryan Scott's avatar
      Add a test case for #15829 · 331081b0
      Ryan Scott authored
      This happened to get fixed as a consequence of commit
      5e45ad10. This adds a test case
      to ensure that it stays fixed.
    • Richard Eisenberg's avatar
    • Richard Eisenberg's avatar
    • Richard Eisenberg's avatar
    • 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
    • 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
      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},
    • Ryan Scott's avatar
      Bump template-haskell version to · e8a652f6
      Ryan Scott authored
      Commit 512eeb9b
      (`More explicit foralls (GHC Proposal 0007)`) introduced breaking
      changes to the Template Haskell AST. As a consequence of this, there
      are libraries in the wild that now fail to build on GHC HEAD (for
      instance, `th-abstraction`).
      This properly bumps the `template-haskell` library's version number
      to `` so that these libraries can guard against these changes
      using `MIN_VERSION_template_haskell`.
      Test Plan: ./validate
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15818
      Differential Revision: https://phabricator.haskell.org/D5272
  2. 28 Oct, 2018 7 commits
    • Zejun Wu's avatar
      Rewrite FastString table in concurrent hashtable · 5126764b
      Zejun Wu authored
      Reimplement global FastString table using a concurrent hashatable with
      fixed size segments and dynamically growing buckets instead of fixed size
      This addresses the problem that `mkFastString` was not linear when the
      total number of entries was large.
      Test Plan:
      inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null
      GHCi, version 8.7.20181005: http://www.haskell.org/ghc/  :? for help
      Prelude> Leaving GHCi.
      FastString stats:
          segments:          256
          buckets:           16384
          entries:           7117
          largest segment:   64
          smallest segment:  64
          longest bucket:    5
          has z-encoding:    0%
      Also comapre the two implementation using
      The new implementation is on a par with the old version with different
      conbination of parameters and perform better when the number of
      FastString's are large.
      Reviewers: simonmar, bgamari, niteria
      Reviewed By: simonmar, bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #14854
      Differential Revision: https://phabricator.haskell.org/D5211
    • Zejun Wu's avatar
      Fix ghc-pkg when only prof way is enabled · e400b9ba
      Zejun Wu authored
      We saw following errors:
      $ cabal install --disable-library-vanilla --disable-shared --enable-library-profiling
      hashable- cannot find any of
      This is because ghc-pkg is looking for
      `libHShashable-` instead of
      Test Plan: ./validate
      Reviewers: simonmar, bgamari
      Reviewed By: simonmar
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5234
    • Ben Gamari's avatar
      testsuite: EtaExpandLevPoly now passes in profiled ways · e69590f1
      Ben Gamari authored
      This failure was originally tracked in #15066 but it seems the problem
      has somehow resolved itself.
      Reviewers: alpmestan
      Reviewed By: alpmestan
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5242
    • sheaf's avatar
      plugins: search for .a files if necessary · be88c818
      sheaf authored
      on windows, plugins are loaded via .a files,
      but those paths were not being searched when loading plugins
      Test Plan: ./validate
      Reviewers: Phyx, bgamari
      Reviewed By: Phyx
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #15700
      Differential Revision: https://phabricator.haskell.org/D5253
    • Christiaan Baaij's avatar
      Comment out CONSTANT_FOLDED in GHC.Natural · 2f2308e2
      Christiaan Baaij authored
      Although these functions were marked as CONSTANT_FOLDED, they did
      not have a corresponding builtinRule in PrelRules. The idea was
      probably to add them eventually, but this hasn't manifested so
      The plan is to eventually add builtin rules for these functions
      over Natural, so as a reminder we simply comment out the
      CONSTANT_FOLDED  annotation instead of removing it completely.
      Reviewers: hvr, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5267
    • Fangyi Zhou's avatar
      Fix integer overflow when encoding doubles (Trac #15271) · 8e1a5593
      Fangyi Zhou authored
      Ticket #15271 reports a case where 1e1000000000 is incorrectly
      converted to 0.0. After some investigation, I discovered the number is
      converted to rational correctly, but converting the ratio into a double
      introduced an error.
      Tracking down to how the conversion is done, I found the rts float
      implementation uses `ldexp`, whose signature is
      `double ldexp (double x, int exp);`
      The callsite passes an `I_` to the second argument, which is
      platform-dependent. On machines where `I_` is 64 bits and `int` is 32 bits, we
      observe integer overflow behaviour.
      Here is a mapping from rational to exponent with observations
      1e646457008  -> 2147483645 (result = infinity, positive in int32)
      1e646457009  -> 2147483648 (result = 0.0, overflow to negative in int32)
      1e1000000000 -> 3321928042 (result = infinity, overflow to positive in int32)
      1e1555550000 -> 5167425196 (result = 0.0, overflow to negative in int32)
      We fix this issue by comparing STG_INT_MIN/MAX and INT_MIN/MAX and bound the
      value appropriately.
      Test Plan: New test cases
      Reviewers: bgamari, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15271
      Differential Revision: https://phabricator.haskell.org/D5271
    • Ningning Xie's avatar
      Fix `:k` command: add validity checking · c4a876d5
      Ningning Xie authored
      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
  3. 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
  4. 26 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix nasty bug in the type free-var finder, at last · 503514b9
      Simon Peyton Jones authored
      Consider the type
        forall k. b -> k
        b :: k -> Type
      Here the 'k' in b's kind must be a different 'k' to the forall k,
      because 'b' is free in the expression.  So we must return 'k'
      among the free vars returned from tyCoVarsOfType applied that
      type.  But we weren't.
      This is an outright bug, although we don't have a program that
      fails because of it.
      It's easy to fix, too: see TyCoRep
        Note [Closing over free variable kinds]
      This fix has been in the pipeline for ages because it fell into
      the Trac #14880 swamp.  But this patch nails it.
  5. 25 Oct, 2018 3 commits
  6. 24 Oct, 2018 8 commits
    • 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
      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.
    • 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"
    • 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.
    • Simon Peyton Jones's avatar
      Improve output from -ddump-types · 321bc1a6
      Simon Peyton Jones authored
      This patch makes a number of improvements to the output
      generated by -ddump-types
      * Prints data constructor separately
      * Omits empty chunks of output
      I was driven initially by the unhelpful existing output for
      data constructors, but ended up doing some refactoring.
      Lots of error message wibbles, but nothing significant.
      Certainly no change in user behaviour.
      (NB: It is just possible that I have failed to cleanly
           separate this patch from the next one, about
           isPredTy and friends.)
    • Ryan Scott's avatar
      Fix #15792 by not reifying invisible arguments in AppTys · bfd93f90
      Ryan Scott authored
      The `reifyType` function in `TcSplice` is carefully designed
      to avoid reifying visible arguments to `TyConApp`s. However, the same
      care was not given towards the `AppTy` case, which lead to #15792.
      This patch changes to the `AppTy` case of `reifyType` so that it
      consults the kind of the function type to determine which of the
      argument types are invisible (and therefore should be dropped) during
      reification. This required crafting a variant of `tyConArgFlags`,
      which I dubbed `appTyArgFlags`, that accept an arbitrary function
      `Type` instead of a `TyCon`.
      Test Plan: make test TEST=T15792
      Reviewers: goldfire, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, carter
      GHC Trac Issues: #15792
      Differential Revision: https://phabricator.haskell.org/D5252
    • Ryan Scott's avatar
      Keep top-level names in typed TH quotes alive · bb835c96
      Ryan Scott authored
      When renaming untyped TH quotes, some care is taken to
      ensure that uses of top-level names in quotes do not have their
      bindings discarded during desugaring. The same care was not applied
      to typed TH quotes, so this patch brings the two into sync.
      Test Plan: make test TEST=T15783
      Reviewers: bgamari, mpickering
      Reviewed By: mpickering
      Subscribers: mpickering, rwbarton, carter
      GHC Trac Issues: #15783
      Differential Revision: https://phabricator.haskell.org/D5248
    • Ryan Scott's avatar
      Fix #15781 by using ktypedocs on type synonym RHSes · 79c641de
      Ryan Scott authored
      This is a follow-up to D5173, which permitted
      unparenthesized kind signatures in certain places. One place that
      appeared to be overlooked was the right-hand sides of type synonyms,
      which this patch addresses by introducing a `ktypedoc` parser
      production (which is to `ctypdoc` as `ktype` is to `ctype`) and
      using it in the right place.
      Test Plan: make test TEST="KindSigs T15781"
      Reviewers: harpocrates, bgamari
      Reviewed By: harpocrates
      Subscribers: rwbarton, mpickering, carter
      GHC Trac Issues: #15781
      Differential Revision: https://phabricator.haskell.org/D5245
    • Alec Theriault's avatar
      Trigger multiline mode in GHCi on '\case' (#13087) · eaf15934
      Alec Theriault authored
      In ALR, 'ITlcase' should expect an opening curly. This is probably a forgotten
      edge case in ALR, since `maybe_layout` (which handles the non-ALR layout)
      already deals with the 'ITlcase' token properly.
      Test Plan: make TEST=T10453 && make TEST=T13087
      Reviewers: bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #10453, #13087
      Differential Revision: https://phabricator.haskell.org/D5236
  7. 22 Oct, 2018 1 commit
  8. 17 Oct, 2018 3 commits
  9. 15 Oct, 2018 9 commits
    • Zejun Wu's avatar
      Allocate bss section within proper range of other sections · 83061413
      Zejun Wu authored
      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
      This depends on {D5195}
      Test Plan:
      1. `./validate`
      `TEST="T15729" make test` passed in both linux and macos.
      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) =
      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/D5219
    • Vladislav Zavialov's avatar
      Enable -Wcompat=error in the testsuite · 165d3d5d
      Vladislav Zavialov authored
      Enabling -Werror=compat in the testsuite allows us to easily see the
      impact that a new warning has on code. It also means that in the period
      between adding the warning and making the actual breaking change, all
      new test cases that are being added to the testsuite will be
      forwards-compatible. This is good because it will make the actual
      breaking change contain less irrelevant testsuite updates.
      Things that -Wcompat warns about are things that are going to break in
      the future, so we can be proactive and keep our testsuite
      This patch consists of two main changes:
      * Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration.
      * Fix all broken test cases.
      Test Plan: Validate
      Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott
      Reviewed By: goldfire, RyanGlScott
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15278
      Differential Revision: https://phabricator.haskell.org/D5200
    • Zejun Wu's avatar
      Generate correct relocation for external cost centre · 95ec7c88
      Zejun Wu authored
      We used to always generate direct access for cost centre labels.  We
      fixed this by generating indirect data load for cost centre defined in
      external module.
      Test Plan:
      The added test used to fail with error message
      /bin/ld.gold: error: T15723B.o: requires dynamic R_X86_64_PC32 reloc
      against 'T15723A_foo1_EXPR_cc' which may overflow at runtime; recompile
      with -fPIC
      and now passes.
      Also check that `R_X86_64_PC32` is generated for CostCentre from the
      same module and `R_X86_64_GOTPCREL` is generated for CostCentre from
      external module:
      $ objdump -rdS T15723B.o
      0000000000000028 <T15723B_test_info>:
        28:   48 8d 45 f0             lea    -0x10(%rbp),%rax
        2c:   4c 39 f8                cmp    %r15,%rax
        2f:   72 70                   jb     a1 <T15723B_test_info+0x79>
        31:   48 83 ec 08             sub    $0x8,%rsp
        35:   48 8d 35 00 00 00 00    lea    0x0(%rip),%rsi        # 3c
                              38: R_X86_64_PC32
        3c:   49 8b bd 60 03 00 00    mov    0x360(%r13),%rdi
        43:   31 c0                   xor    %eax,%eax
        45:   e8 00 00 00 00          callq  4a <T15723B_test_info+0x22>
                              46: R_X86_64_PLT32      pushCostCentre-0x4
        4a:   48 83 c4 08             add    $0x8,%rsp
        4e:   48 ff 40 30             incq   0x30(%rax)
        52:   49 89 85 60 03 00 00    mov    %rax,0x360(%r13)
        59:   48 83 ec 08             sub    $0x8,%rsp
        5d:   49 8b bd 60 03 00 00    mov    0x360(%r13),%rdi
        64:   48 8b 35 00 00 00 00    mov    0x0(%rip),%rsi        # 6b
                              67: R_X86_64_GOTPCREL   T15723A_foo1_EXPR_cc-0x4
        6b:   31 c0                   xor    %eax,%eax
        6d:   e8 00 00 00 00          callq  72 <T15723B_test_info+0x4a>
                              6e: R_X86_64_PLT32      pushCostCentre-0x4
        72:   48 83 c4 08             add    $0x8,%rsp
        76:   48 ff 40 30             incq   0x30(%rax)
      Reviewers: simonmar, bgamari
      Reviewed By: simonmar
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15723
      Differential Revision: https://phabricator.haskell.org/D5214
    • Ryan Scott's avatar
      Fix #15738 by defining (and using) parenthesizeHsContext · 02b2116e
      Ryan Scott authored
      With `QuantifiedConstraints`, `forall`s can appear in more
      nested positions than they could before, but `Convert` and the TH
      pretty-printer were failing to take this into account. On the
      `Convert` side, this is fixed by using a `parenthesizeHsContext`
      to parenthesize singleton quantified constraints that appear to the
      left of a `=>`. (A similar fix is applied to the TH pretty-printer.)
      Test Plan: make test TEST=T15738
      Reviewers: goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15738
      Differential Revision: https://phabricator.haskell.org/D5222
    • Ryan Scott's avatar
      Fix #12430 by expanding type synonyms in injTyVarsOfType · 26e81e90
      Ryan Scott authored
      We weren't expanding type synonyms when determining the
      injective type variables of a type, leading to certain non-injective
      families being mistakenly labeled as injective (#12430). Easily fixed
      with a tactical use of `coreView`.
      Test Plan: make test TEST=T12430
      Reviewers: bgamari, goldfire
      Reviewed By: goldfire
      Subscribers: goldfire, rwbarton, carter
      GHC Trac Issues: #12430
      Differential Revision: https://phabricator.haskell.org/D5228
    • Sasa Bogicevic's avatar
      Surprising error message with bang pattern · 0b0cb484
      Sasa Bogicevic authored
      Reviewers: bgamari, alanz
      Reviewed By: bgamari
      Subscribers: sgraf, mpickering, rwbarton, thomie, carter
      GHC Trac Issues: #13600
      Differential Revision: https://phabricator.haskell.org/D5040
    • Ben Gamari's avatar
      Typeable: Only render saturated tuple types with tuple syntax · 846fe904
      Ben Gamari authored
      This isn't as efficient as it could be since it needs to compute the
      kind of the type. However, this is `show` so there shouldn't be any
      particular expectation of speed.
      Fixes #14341.
      Test Plan: Validate
      Reviewers: hvr
      Subscribers: monoidal, rwbarton, carter
      GHC Trac Issues: #14341
      Differential Revision: https://phabricator.haskell.org/D5080
    • Tamar Christina's avatar
      Fix plugin tests requirements · 01c3d00a
      Tamar Christina authored
      Unfortunately the implementation has confused the ability to make
      dynamic libraries with dynamic way.
      This constraint is only true for systems that require `-fPIC` for
      shared libraries.
      Since the implementation has this implicit assumption, mark the tests
      as requiring dynway.
      Test Plan: ./validate
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: simonpj, rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5174
    • Ryan Scott's avatar
      Fix #15725 with an extra Sym · 48efbc04
      Ryan Scott authored
      We were adding a `Sym` to one argument in the `InstCo`
      case of `optCoercion` but not another, leading to the two arguments
      to misaligned when combined via `Trans`. This fixes the issue with
      a well targeted use of `wrapSym`.
      Test Plan: make test TEST=T15725
      Reviewers: goldfire, ningning, bgamari
      Reviewed By: goldfire, ningning
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15725
      Differential Revision: https://phabricator.haskell.org/D5217