1. 29 Oct, 2018 17 commits
    • Sylvain Henry's avatar
      Correctly detect GIT in a subtree · 66cb344d
      Sylvain Henry authored
      When we use a git subtree, .git is a file, not a directory.
      The script was already fixed for the commit ID but not for its date.
      PR: https://github.com/ghc/ghc/pull/212/
    • Ben Gamari's avatar
      circleci: Build with in-tree GMP on Darwin · 78fb3107
      Ben Gamari authored
      Fixes #15404.
      (cherry picked from commit 578012be)
    • Nathan Collins's avatar
      Improve documentation for warning options · b8e30e40
      Nathan Collins authored
      My main goal was to make it easy to discover how to reverse `-Werror`,
      since `Wno-error` doesn't work, and the fact that `-Wwarn` negates
      `-Werror` was only mentioned in the `-Wwarn` docs before.
      Other changes:
      - explain at the outset that some options control individual warnings
        while others control warning families.
      - explain at the outset that `-Wno-<wflag>` can be used to reverse
        `-W<wflag>`. This is no mentioned in two places, but I don't think
        that's a bad thing.
    • Ian Denhardt's avatar
      Docs: clarify the interaction between throwSTM and catchSTM. · 503ddd6e
      Ian Denhardt authored
      The previous doc comments were not terribly clear on what was or wasn't
      rolled back when an exception was caught in STM. This misunderstanding
      was the source of a bug in another project of mine, and folks on
      `#haskell` found it confusing as well.
    • Yuji Yamamoto's avatar
      Fix sample code of -fprint-explicit-kinds, plus sample when disabling PolyKinds · 44a1d1f6
      Yuji Yamamoto authored
      - Although the sample is for `-fprint-explicit-kinds`, the sample code
        uses `-fprint-explicit-foralls` (but perhaps the output used to be
        correct one of `-fprint-explicit-kinds`).
      - Update the output with the recent version of GHC (ver. 8.4.3. I guess
        it doesn't change in GHC 8.6...)
      - Add more samples to clarify the difference of kinds, which tells
        effect of `-fprint-explicit-kinds` more clearly.
    • Ben Gamari's avatar
      users guide: Introduce :pragma: directive · e35ed9dc
      Ben Gamari authored
    • Ben Gamari's avatar
      users guide: Mention :since: in editing-guide · b2db706f
      Ben Gamari authored
    • Ryan Scott's avatar
      Fix #15815 by parenthesizing the arguments to infix ~ · b8a797ec
      Ryan Scott authored
      An unfortunate consequence of commit
      b9483981 (`Remove HsEqTy and XEqTy`)
      is infix uses of `~` in TH quotes now desugar differently than
      before. In particular, we have that:
      a ~ (Int -> Int)
      Now desugars to:
      HsOpTy a (~) (HsOpTy Int (->) Int)
      Which GHC interprets as being:
      a ~ Int -> Int
      Or, equivalently:
      (a ~ Int) -> Int
      Which is different than what was intended! This is the cause
      of #15815.
      All of this has revealed that we likely need to renovate the way we
      desugar infix type operators to be more consistent with the treatment
      for infix expressions (see
      https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on
      this.) Doing so would constitute a breaking change, however, so we
      will likely want to wait until another major GHC release to do this.
      In the meantime, this patch offers a non-invasive change to the way
      that infix uses of `~` are desugared. This makes the program
      in #15815 compile again by inserting extra `HsParTy`s around the
      arguments to `~` if they are lacking them.
      Test Plan: make test TEST=T15815
      Reviewers: int-index, goldfire, bgamari
      Reviewed By: int-index
      Subscribers: int-e, rwbarton, carter
      GHC Trac Issues: #15815
      Differential Revision: https://phabricator.haskell.org/D5274
    • 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
      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.
    • Richard Eisenberg's avatar
    • Richard Eisenberg's avatar
    • Richard Eisenberg's avatar
    • 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.
    • 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 13 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
    • Victor Nawothnig's avatar
      Improve diagnostic when using `make fast` in top directory · 42575701
      Victor Nawothnig authored
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5113
    • 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
      Plugins: Add documentation and missing exports · 49f5c6c3
      Ben Gamari authored
      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
    • 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
    • Ningning Xie's avatar
      Fix TcType.anyRewritableTyVar · a7f64c6c
      Ningning Xie authored
      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
    • 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
    • Ben Gamari's avatar
      includes: Allow headers to be built with C++11 compilers · 134de451
      Ben Gamari authored
      Fixes #14784. Note that C++11 is quite conservative; we could likely accept
      C++03 as well.
      Test Plan:
      $ cat >hi.c <<EOF
      #include <Rts.h>
      $ g++ -std=c++11 hi.c
      Reviewers: simonmar, hvr
      Subscribers: rwbarton, carter
      GHC Trac Issues: #14784
      Differential Revision: https://phabricator.haskell.org/D5244
    • Zejun Wu's avatar
      Fix rare undefined asm temp end label error in x86 · 3c452d0d
      Zejun Wu authored
      Encountered assembly error due to undefined label `.LcaDcU_info_end` for
      following code generated by `pprFrameProc`:
        .long .Lblock{v caDcU}_info_fde_end-.Lblock{v caDcU}_info_fde
      .Lblock{v caDcU}_info_fde:
        .long _nbHlD-.Lsection_frame
        .quad block{v caDcU}_info-1
        .quad .Lblock{v caDcU}_info_end-block{v caDcU}_info+1
        .byte 1
      This diff fixed the error.
      Test Plan:
      Also the case where we used to have assembly error is now fixed.
      Unfortunately, I have limited insight here and cannot get a small enough repro
      or test case for this.
      Ben says:
      > I think I see: Previously we only produced end symbols for the info
      > tables of top-level procedures. However, blocks within a procedure may
      > also have info tables, we will dutifully generate debug information for
      > and consequently we get undefined symbols.
      Reviewers: simonmar, scpmw, last_g, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5246
    • Kavon Farvardin's avatar
      Fix for T14251 on ARM · d8495549
      Kavon Farvardin authored
      We now calculate the SSE register padding needed to fix the calling
      convention in LLVM in a robust way: grouping them by whether
      registers in that class overlap (with the same class overlapping
      My prior patch assumed that no matter the platform, physical
      register Fx aliases with Dx, etc, for our calling convention.
      This is unfortunately not the case for any platform except x86-64.
      Test Plan:
      Only know how to test on x86-64, but it should be tested on ARM with:
      `make test WAYS=llvm && make test WAYS=optllvm`
      Reviewers: bgamari, angerman
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15780, #14251, #15747
      Differential Revision: https://phabricator.haskell.org/D5254
  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 4 commits
    • Simon Jakobi's avatar
      Remove redundant SOURCE import · 23956b2a
      Simon Jakobi authored
    • 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.
    • 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]
    • 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.
  5. 25 Oct, 2018 5 commits