This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 06 Aug, 2018 11 commits
  2. 03 Aug, 2018 1 commit
  3. 02 Aug, 2018 7 commits
    • Matthías Páll Gissurarson's avatar
      Clone relevant constraints to avoid side-effects on HoleDests. Fixes #15370. · 588364c3
      Matthías Páll Gissurarson authored
      Summary: When looking for valid hole fits, the constraints relevant
      to the hole may sometimes contain a HoleDest. Previously,
      these were not cloned, which could cause the filling of filled
      coercion hole being, which would cause an assert to fail. This is now fixed.
      
      Test Plan: Regression test included.
      
      Reviewers: simonpj, bgamari, goldfire
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15370
      
      Differential Revision: https://phabricator.haskell.org/D5004
      
      (cherry picked from commit 0dc86f6b)
      588364c3
    • Christiaan Baaij's avatar
      Plugin dependency information is stored separately · e86db0d5
      Christiaan Baaij authored
      We need to store the used plugins so that we recompile
      a module when a plugin that it uses is recompiled.
      
      However, storing the `ModuleName`s of the plugins used by a
      module in the `dep_mods` field made the rest of GHC think
      that they belong in the HPT, causing at least the issues
      reported in #15234
      
      We therefor store the `ModuleName`s of the plugins in a
      new field, `dep_plgins`, which is only used the the
      recompilation logic.
      
      Reviewers: mpickering, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: alpmestan, rwbarton, thomie, carter
      
      GHC Trac Issues: #15234
      
      Differential Revision: https://phabricator.haskell.org/D4937
      
      (cherry picked from commit 52065e95)
      e86db0d5
    • Simon Peyton Jones's avatar
      Treat isConstraintKind more consistently · 6a7cb806
      Simon Peyton Jones authored
      It turned out that we were not being consistent
      about our use of isConstraintKind.
      
      It's delicate, because the typechecker treats Constraint and Type as
      /distinct/, whereas they are the /same/ in the rest of the compiler
      (Trac #11715).
      
      And had it wrong, which led to Trac #15412.  This patch does the
      following:
      
      * Rename isConstraintKind      to tcIsConstraintKind
               returnsConstraintKind to tcReturnsConstraintKind
        to emphasise that they use the 'tcView' view of types.
      
      * Move these functions, and some related ones (tcIsLiftedTypeKind),
        from Kind.hs, to group together in Type.hs, alongside isPredTy.
      
      It feels very unsatisfactory that these 'tcX' functions live in Type,
      but it happens because isPredTy is called later in the compiler
      too.  But it's a consequence of the 'Constraint vs Type' dilemma.
      
      (cherry picked from commit c5d31df7)
      6a7cb806
    • Ryan Scott's avatar
      Fix #15385 by using addDictsDs in matchGuards · e649085b
      Ryan Scott authored
      When coverage checking pattern-matches, we rely on the call
      sites in the desugarer to populate the local dictionaries and term
      evidence in scope using `addDictsDs` and `addTmCsDs`. But it turns
      out that only the call site for desugaring `case` expressions was
      actually doing this properly. In another part of the desugarer,
      `matchGuards` (which handles pattern guards), it did not update the
      local dictionaries in scope at all, leading to #15385.
      
      Fixing this is relatively straightforward: just augment the
      `BindStmt` case of `matchGuards` to use `addDictsDs` and `addTmCsDs`.
      Accomplishing this took a little bit of import/export tweaking:
      
      * We now need to export `collectEvVarsPat` from `HsPat.hs`.
      * To avoid an import cycle with `Check.hs`, I moved `isTrueLHsExpr`
        from `DsGRHSs.hs` to `DsUtils.hs`, which resides lower on the
        import chain.
      
      Test Plan: make test TEST=T15385
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15385
      
      Differential Revision: https://phabricator.haskell.org/D4968
      
      (cherry picked from commit 9d388eb8)
      e649085b
    • Simon Peyton Jones's avatar
      Small refactor in desugar of pattern matching · 42c51e2f
      Simon Peyton Jones authored
      In reviewing Phab:D4968 for Trac #15385 I saw a small
      but simple refactor to avoid unnecessary work in the
      desugarer.
      
      This patch just arranges to call
         matchSinglePatVar v ...
      rather than
         matchSinglePat (Var v) ...
      
      The more specialised function already existed, as
         match_single_pat_var
      
      I also added more comments about decideBangHood
      
      (cherry picked from commit 45cfe651)
      42c51e2f
    • Richard Eisenberg's avatar
      Remove the type-checking knot. · 59f38587
      Richard Eisenberg authored
      Bug #15380 hangs because a knot-tied TyCon ended up in a kind.
      Looking at the code in tcInferApps, I'm amazed this hasn't happened
      before! I couldn't think of a good way to fix it (with dependent
      types, we can't really keep types out of kinds, after all), so
      I just went ahead and removed the knot.
      
      This was remarkably easy to do. In tcTyVar, when we find a TcTyCon,
      just use it. (Previously, we looked up the knot-tied TyCon and used
      that.) Then, during the final zonk, replace TcTyCons with the real,
      full-blooded TyCons in the global environment. It's all very easy.
      
      The new bit is explained in the existing
      Note [Type checking recursive type and class declarations]
      in TcTyClsDecls.
      
      Naturally, I removed various references to the knot and the
      zonkTcTypeInKnot (and related) functions. Now, we can print types
      during type checking with abandon!
      
      NB: There is a teensy error message regression with this patch,
      around the ordering of quantified type variables. This ordering
      problem is fixed (I believe) with the patch for #14880. The ordering
      affects only internal variables that cannot be instantiated with
      any kind of visible type application.
      
      There is also a teensy regression around the printing of types
      in TH splices. I think this is really a TH bug and will file
      separately.
      
      Test case: dependent/should_fail/T15380
      
      (cherry picked from commit f8618a9b)
      59f38587
    • Ben Gamari's avatar
      Bump Cabal submodule to 2.4 · ff086cc1
      Ben Gamari authored
      ff086cc1
  4. 01 Aug, 2018 5 commits
    • Ryan Scott's avatar
      Fix #15450 by refactoring checkEmptyCase' · ebd773a0
      Ryan Scott authored
      `checkEmptyCase'` (the code path for coverage-checking
      `EmptyCase` expressions) had a fair bit of code duplication from the
      code path for coverage-checking non-`EmptyCase` expressions, and to
      make things worse, it behaved subtly different in some respects (for
      instance, emitting different warnings under unsatisfiable
      constraints, as shown in #15450). This patch attempts to clean up
      both this discrepancy and the code duplication by doing the
      following:
      
      * Factor out a `pmInitialTmTyCs` function, which returns the initial
        set of term and type constraints to use when beginning coverage
        checking. If either set of constraints is unsatisfiable, we use an
        empty set in its place so that we can continue to emit as many
        warnings as possible. (The code path for non-`EmptyCase`
        expressions was doing this already, but not the code path for
        `EmptyCase` expressions, which is the root cause of #15450.)
      
        Along the way, I added a `Note` to explain why we do this.
      * Factor out a `pmIsSatisfiable` constraint which checks if a set of
        term and type constraints are satisfiable. This does not change any
        existing behavior; this is just for the sake of deduplicating code.
      
      Test Plan: make test TEST=T15450
      
      Reviewers: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15450
      
      Differential Revision: https://phabricator.haskell.org/D5017
      
      (cherry picked from commit 7f3cb50d)
      ebd773a0
    • Vladislav Zavialov's avatar
      Fix #15415 and simplify tcWildCardBinders · a97ead78
      Vladislav Zavialov authored
      Test Plan: Validate
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #15415
      
      Differential Revision: https://phabricator.haskell.org/D5022
      
      (cherry picked from commit 120cc9f8)
      a97ead78
    • Moritz Angermann's avatar
      linker: Nub rpaths · c9be8596
      Moritz Angermann authored
      When compiling and linking files in `ghci`, we keep adding rpath
      arguments to the linker command invoation.  If those are identical we
      should `nub` them out.  Otherwise we not only risk overflowing the
      argument limit, but also embed huge amounts of identical rpath values
      into the dynamic library, eventually leading to the overflow of the load
      command size limit, due to the number of rpath entries alone.
      
      A further improvement could be to pass `-Xlinker -dead_strip_dylibs`;
      that however might be stipping too aggressively, and potentially lead to
      missing symbols?
      
      For the time being I suggest to only do the nubbing and if need be to
      provide -Wl,-dead_strip_dylibs when invoking ghci.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15446
      
      Differential Revision: https://phabricator.haskell.org/D5021
      
      (cherry picked from commit b803c406)
      c9be8596
    • Ningning Xie's avatar
      Fix #15453: bug in ForAllCo case in opt_trans_rule · eb2b71c5
      Ningning Xie authored
      Summary:
      Given
      
      ```
      co1 = \/ tv1 : eta1. r1
      co2 = \/ tv2 : eta2. r2
      ```
      
      We would like to optimize `co1; co2` so we push transitivity inside forall.
      It should be
      
      ```
      \/tv1 : (eta1;eta2).  (r1; r2[tv2 |-> tv1 |> eta1])
      ```
      
      It is implemented in the ForAllCo case in opt_trans_rule in OptCoercion.
      However current implementation is not right:
      
      ```
      r2' = substCoWithUnchecked [tv2] [TyVarTy tv1] r2 -- ill-kinded!
      ```
      
      This patch corrects it to be
      
      ```
      r2' = substCoWithUnchecked [tv2] [mkCastTy (TyVarTy tv1) eta1] r2
      ```
      
      Test Plan: validate
      
      Reviewers: bgamari, goldfire, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15453
      
      Differential Revision: https://phabricator.haskell.org/D5018
      
      (cherry picked from commit 11de4380)
      eb2b71c5
    • Ben Gamari's avatar
      Enable two-step allocator on FreeBSD · 79e13610
      Ben Gamari authored
      Simplify #ifdef nesting and use MAP_GUARD on FreeBSD and similar
      systems. This allows the two-step allocator to be used on FreeBSD,
      fixing #15348.
      
      (cherry picked from commit 123aeb91)
      79e13610
  5. 31 Jul, 2018 15 commits
    • Richard Eisenberg's avatar
      testsuite: Add test for #15346 · f579162a
      Richard Eisenberg authored
      Test case: dependent/should_compile/T{15346,15419}.
      f579162a
    • Ben Gamari's avatar
      Fix some casts. · 06c29ddc
      Ben Gamari authored
      This fixes #15346, and is a team effort between Ryan Scott and
      myself (mostly Ryan). We discovered two errors related to FC's
      "push" rules, one in the TPush rule (as implemented in pushCoTyArg)
      and one in KPush rule (it shows up in liftCoSubstVarBndr).
      
      The solution: do what the paper says, instead of whatever random
      thoughts popped into my head as I was actually implementing.
      
      Note that this is a backport of the fix merged to master,
      af624071.
      
      Also fixes #15419, which is actually the same underlying problem.
      
      Test case: dependent/should_compile/T{15346,15419}.
      06c29ddc
    • Sylvain Henry's avatar
      Fix Git commit ID detection in Git worktrees · 2a162eba
      Sylvain Henry authored
      Summary: When using a Git worktree, ".git" is a file, not a directory
      
      Reviewers: bgamari, monoidal
      
      Reviewed By: monoidal
      
      Subscribers: rwbarton, thomie, erikd, carter
      
      Differential Revision: https://phabricator.haskell.org/D5016
      
      (cherry picked from commit 3539561b)
      2a162eba
    • Simon Peyton Jones's avatar
      Fix PrelRules.caseRules to account for out-of-range tags · 851f3341
      Simon Peyton Jones authored
      As Trac #15436 points out, it is possible to get
         case dataToTag# (x :: T) of
            DEFAULT -> blah1
            -1#     -> blah2
            0       -> blah3
      
      The (-1#) alterantive is unreachable, because dataToTag# returns
      tags in the range [0..n-1] where n is the number of data constructors
      in type T.
      
      This actually made GHC crash; now we simply discard the unreachable
      alterantive.  See Note [Unreachable caseRules alternatives]
      in PrelRules
      
      (cherry picked from commit 9897f678)
      851f3341
    • Simon Peyton Jones's avatar
      Stop marking soluble ~R# constraints as insoluble · 09abd1c4
      Simon Peyton Jones authored
      We had a constraint (a b ~R# Int), and were marking it as 'insoluble'.
      That's bad; it isn't.  And it caused Trac #15431. Soultion is simple.
      
      I did a tiny refactor on can_eq_app, so that it is used only for
      nominal equalities.
      
      (cherry picked from commit f0d27f51)
      09abd1c4
    • Ryan Scott's avatar
      Fix #15423 by using pprAStmtContext · ff839f20
      Ryan Scott authored
      Summary:
      Previously, we were using `pprStmtContext` instead, which
      led to error messages missing indefinite articles where they were
      required.
      
      Test Plan: make test TEST="T13242a T7786 Typeable1"
      
      Reviewers: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15423
      
      Differential Revision: https://phabricator.haskell.org/D4992
      
      (cherry picked from commit 99f45e2a)
      ff839f20
    • Simon Marlow's avatar
      Fix the GHCi debugger with ApplicativeDo · d170083b
      Simon Marlow authored
      Summary:
      `collectLStmtsBinders` was returning nothing for `ApplicativeStmts`, which
      caused the debugger to not track free variables in many cases when using
      `ApplicativeDo`.
      
      Test Plan:
      * new test case
      * validate
      
      Reviewers: bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15422
      
      Differential Revision: https://phabricator.haskell.org/D4991
      
      (cherry picked from commit 4ea9311c)
      d170083b
    • Ryan Scott's avatar
      Suppress -Winaccessible-code in derived code · 8bed1400
      Ryan Scott authored
      Summary:
      It's rather unfortunate that derived code can produce inaccessible
      code warnings (as demonstrated in #8128, #8740, and #15398), since
      the programmer has no control over the generated code. This patch
      aims to suppress `-Winaccessible-code` in all derived code. It
      accomplishes this by doing the following:
      
      * Generalize the `ic_env :: TcLclEnv` field of `Implication` to
        be of type `Env TcGblEnc TcLclEnv` instead. This way, it also
        captures `DynFlags`, which record the flag state at the time
        the `Implication` was created.
      * When typechecking derived code, turn off `-Winaccessible-code`.
        This way, any insoluble given `Implication`s that are created when
        typechecking this derived code will remember that
        `-Winaccessible-code` was disabled.
      * During error reporting, consult the `DynFlags` of an
        `Implication` before making the decision to report an inaccessible
        code warning.
      
      Test Plan: make test TEST="T8128 T8740 T15398"
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: monoidal, rwbarton, thomie, carter
      
      GHC Trac Issues: #8128, #8740, #15398
      
      Differential Revision: https://phabricator.haskell.org/D4993
      
      (cherry picked from commit 44a7b9ba)
      8bed1400
    • Krzysztof Gogolewski's avatar
      Fix Ar crashing on odd-sized object files (Trac #15396) · 04805078
      Krzysztof Gogolewski authored
      Summary: All the work was done by Moritz Angermann.
      
      Test Plan: validate
      
      Reviewers: angerman, RyanGlScott, bgamari
      
      Reviewed By: angerman
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15396
      
      Differential Revision: https://phabricator.haskell.org/D5013
      
      (cherry picked from commit 754c3a55)
      04805078
    • Krzysztof Gogolewski's avatar
      Fix pretty-printing of data declarations in splices · 4c044ed1
      Krzysztof Gogolewski authored
      Test Plan: validate
      
      Reviewers: RyanGlScott, bgamari
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15365
      
      Differential Revision: https://phabricator.haskell.org/D4998
      
      (cherry picked from commit 3aa09cc5)
      4c044ed1
    • David Feuer's avatar
      Harden fixST · 39ab54c9
      David Feuer authored
      Trac #15349 reveals that lazy blackholing can cause trouble for
      `fixST` much like it can for `fixIO`. Make `fixST` work just
      like `fixIO`.
      
      Reviewers: simonmar, hvr, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15349
      
      Differential Revision: https://phabricator.haskell.org/D4948
      
      (cherry picked from commit 5a49651f)
      39ab54c9
    • Krzysztof Gogolewski's avatar
      Fix a major copy'n'paste error in LLVM CodeGen · 9a4ac756
      Krzysztof Gogolewski authored
      Summary:
      In D4592, `AddWordC` is lowered as an unsigned subtraction instead
      of an unsigned addition when compiling with LLVM.
      
      This patch rectifies that.
      
      Reviewers: angerman, bgamari, monoidal
      
      Reviewed By: angerman, bgamari, monoidal
      
      Subscribers: osa1, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4969
      
      (cherry picked from commit f629442b)
      9a4ac756
    • Tamar Christina's avatar
      stack: fix stack allocations on Windows · b6a2c0d9
      Tamar Christina authored
      Summary:
      On Windows one is not allowed to drop the stack by more than a page size.
      The reason for this is that the OS only allocates enough stack till what
      the TEB specifies. After that a guard page is placed and the rest of the
      virtual address space is unmapped.
      
      The intention is that doing stack allocations will cause you to hit the
      guard which will then map the next page in and move the guard.  This is
      done to prevent what in the Linux world is known as stack clash
      vulnerabilities https://access.redhat.com/security/cve/cve-2017-1000364.
      
      There are modules in GHC for which the liveliness analysis thinks the
      reserved 8KB of spill slots isn't enough.  One being DynFlags and the
      other being Cabal.
      
      Though I think the Cabal one is likely a bug:
      
      ```
        4d6544:       81 ec 00 46 00 00       sub    $0x4600,%esp
        4d654a:       8d 85 94 fe ff ff       lea    -0x16c(%ebp),%eax
        4d6550:       3b 83 1c 03 00 00       cmp    0x31c(%ebx),%eax
        4d6556:       0f 82 de 8d 02 00       jb     4ff33a <_cLpg_info+0x7a>
        4d655c:       c7 45 fc 14 3d 50 00    movl   $0x503d14,-0x4(%ebp)
        4d6563:       8b 75 0c                mov    0xc(%ebp),%esi
        4d6566:       83 c5 fc                add    $0xfffffffc,%ebp
        4d6569:       66 f7 c6 03 00          test   $0x3,%si
        4d656e:       0f 85 a6 d7 02 00       jne    503d1a <_cLpb_info+0x6>
        4d6574:       81 c4 00 46 00 00       add    $0x4600,%esp
      ```
      
      It allocates nearly 18KB of spill slots for a simple 4 line function
      and doesn't even use it.  Note that this doesn't happen on x64 or
      when making a validate build.  Only when making a build without a
      validate and build.mk.
      
      This and the allocation in DynFlags means the stack allocation will jump
      over the guard page into unmapped memory areas and GHC or an end program
      segfaults.
      
      The pagesize on x86 Windows is 4KB which means we hit it very easily for
      these two modules, which explains the total DOA of GHC 32bit for the past
      3 releases and the "random" segfaults on Windows.
      
      ```
      0:000> bp 00503d29
      0:000> gn
      Breakpoint 0 hit
      WARNING: Stack overflow detected. The unwound frames are extracted from outside
               normal stack bounds.
      eax=03b6b9c9 ebx=00dc90f0 ecx=03cac48c edx=03cac43d esi=03b6b9c9 edi=03abef40
      eip=00503d29 esp=013e96fc ebp=03cf8f70 iopl=0         nv up ei pl nz na po nc
      cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
      setup+0x103d29:
      00503d29 89442440        mov     dword ptr [esp+40h],eax ss:002b:013e973c=????????
      WARNING: Stack overflow detected. The unwound frames are extracted from outside
               normal stack bounds.
      WARNING: Stack overflow detected. The unwound frames are extracted from outside
               normal stack bounds.
      0:000> !teb
      TEB at 00384000
          ExceptionList:        013effcc
          StackBase:            013f0000
          StackLimit:           013eb000
      ```
      
      This doesn't fix the liveliness analysis but does fix the allocations, by
      emitting a function call to `__chkstk_ms` when doing allocations of larger
      than a page, this will make sure the stack is probed every page so the kernel
      maps in the next page.
      
      `__chkstk_ms` is provided by `libGCC`, which is under the
      `GNU runtime exclusion license`, so it's safe to link against it, even for
      proprietary code. (Technically we already do since we link compiled C code in.)
      
      For allocations smaller than a page we drop the stack and probe the new address.
      This avoids the function call and still makes sure we hit the guard if needed.
      
      PS: In case anyone is Wondering why we didn't notice this before, it's because we
      only test x86_64 and on Windows 10.  On x86_64 the page size is 8KB and also the
      kernel is a bit more lenient on Windows 10 in that it seems to catch the segfault
      and resize the stack if it was unmapped:
      
      ```
      0:000> t
      eax=03b6b9c9 ebx=00dc90f0 ecx=03cac48c edx=03cac43d esi=03b6b9c9 edi=03abef40
      eip=00503d2d esp=013e96fc ebp=03cf8f70 iopl=0         nv up ei pl nz na po nc
      cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
      setup+0x103d2d:
      00503d2d 8b461b          mov     eax,dword ptr [esi+1Bh] ds:002b:03b6b9e4=03cac431
      0:000> !teb
      TEB at 00384000
          ExceptionList:        013effcc
          StackBase:            013f0000
          StackLimit:           013e9000
      ```
      
      Likely Windows 10 has a guard page larger than previous versions.
      
      This fixes the stack allocations, and as soon as I get the time I will look at
      the liveliness analysis. I find it highly unlikely that simple Cabal function
      requires ~2200 spill slots.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: AndreasK, rwbarton, thomie, carter
      
      GHC Trac Issues: #15154
      
      Differential Revision: https://phabricator.haskell.org/D4917
      
      (cherry picked from commit d0bbe1bf)
      b6a2c0d9
    • Simon Peyton Jones's avatar
      Fix a nasty bug in piResultTys · a107cced
      Simon Peyton Jones authored
      I was failing to instantiate vigorously enough in Type.piResultTys
      and in the very similar function ToIface.toIfaceAppArgsX
      
      This caused Trac #15428.  The fix is easy.
      
      See Note [Care with kind instantiation] in Type.hs
      
      (cherry picked from commit e1b5a117)
      a107cced
    • Sylvain Henry's avatar
      testsuite: Add test for #14346 · 96609122
      Sylvain Henry authored
      (cherry picked from commit f8e5da92)
      96609122
  6. 30 Jul, 2018 1 commit