1. 06 Sep, 2021 1 commit
  2. 01 Sep, 2021 1 commit
    • Hai Nguyen Quang's avatar
      Convert diagnostics in GHC.Tc.Validity to proper TcRnMessage. · af41496f
      Hai Nguyen Quang authored
      - Add 19 new messages. Update test outputs accordingly.
      - Pretty print suggest-extensions hints: remove space before
      interspersed commas.
      - Refactor Rank's MonoType constructors. Each MonoType constructor
      should represent a specific case. With the Doc suggestion belonging
      to the TcRnMessage diagnostics instead.
      - Move Rank from Validity to its own `GHC.Tc.Types.Rank` module.
      - Remove the outdated `check_irred_pred` check.
      - Remove the outdated duplication check in `check_valid_theta`, which
      was subsumed by `redundant-constraints`.
      - Add missing test cases for quantified-constraints/T16474 & th/T12387a.
  3. 28 Aug, 2021 3 commits
  4. 27 Aug, 2021 2 commits
  5. 26 Aug, 2021 2 commits
    • Simon Peyton Jones's avatar
      Fix GHC.Core.Subst.substDVarSet · d551199c
      Simon Peyton Jones authored
      substDVarSet looked up coercion variables in the wrong environment!
      The fix is easy.  It is still a pretty strange looking function, but
      the bug is gone.  This fixes another manifestation of #20200.
    • Sebastian Graf's avatar
      CallArity: Consider shadowing introduced by case and field binders · b3653351
      Sebastian Graf authored
      In #20283, we saw a regression in `simple` due to CallArity for a very subtle
      reason: It simply didn't handle shadowing of case binders and constructor field
      The test case T20283 has a very interesting binding `n_X1` that we want to
      eta-expand and that has a Unique (on GHC HEAD) that is reused by the Simplifier
      for a case binder:
        let { n_X1 = ... } in
            let {
                = ... case x_a1Rg of wild_X1 {
                        __DEFAULT -> f_s1Tx rho_value_awA (GHC.Types.I# wild_X1);
                        0# -> lvl_s1TN
                      } ...
                } in
            letrec {
                = \ (x_X4 :: GHC.Prim.Int#) (v_a1P9 [OS=OneShot] :: Double) ->
                    let {
                      karg_s1Wu = ...
                                          case lvl_s1Ul of { GHC.Types.D# y_a1Qf ->
                          } } in
                    case GHC.Prim.==# x_X4 y_a1R7 of {
                      __DEFAULT -> go3_X3 (GHC.Prim.+# x_X4 1#) karg_s1Wu;
                      1# -> n_X1 karg_s1Wu -- Here we will assume that karg calls n_X1!
                    }; } in
            go3_X3 0#;
      Since the Case case of CallArity doesn't delete `X1` from the set of variables
      it is interested in knowing the usages of, we leak a very boring usage (of the
      case binder!) into the co-call graph that we mistakenly take for a usage of
      `n_X1`. We conclude that `lvl_s1Ul` and transitively `karg_s1Wu` call `n_X1`
      when really they don't. That culminates in the conclusion that `n_X1 karg_s1Wu`
      calls `n_X1` more than once. Wrong!
      Fortunately, this bug (which has been there right from CallArity's inception,
      I suppose) will never lead to a CallArity that is too optimistic. So by fixing
      this bug, we get strictly more opportunities for CallArity and all of them
      should be sound to exploit.
      Fixes #20283.
  6. 25 Aug, 2021 1 commit
    • Ryan Scott's avatar
      Desugarer: Bring existentials in scope when substituting into record GADTs · 0759c069
      Ryan Scott authored
      This fixes an outright bug in which the desugarer did not bring the
      existentially quantified type variables of a record GADT into `in_subst`'s
      in-scope set, leading to #20278. It also addresses a minor inefficiency in
      which `out_subst` was made into a substitution when a simpler `TvSubstEnv`
      would suffice.
      Fixes #20278.
  7. 24 Aug, 2021 7 commits
  8. 23 Aug, 2021 9 commits
    • andreas.abel's avatar
      Doc fix #20226: formatting issues in 9.2.1 release notes · d94e7ebd
      andreas.abel authored
      RST is brittle...
    • andreas.abel's avatar
    • Krzysztof Gogolewski's avatar
    • Matthew Pickering's avatar
      driver: Only check for unused package warning in after succesful downsweep · c1acfd21
      Matthew Pickering authored
      Before we would check for the unused package warning even if the module
      graph was compromised due to an error in downsweep. This is easily
      fixed by pushing warmUnusedPackages into depanalE, and then returning
      the errors like the other downsweep errors.
      Fixes #20242
    • Sebastian Graf's avatar
      Pmc: Better SCC annotations and trace output · 06aa8da5
      Sebastian Graf authored
      While investigating #20106, I made a few refactorings to the pattern-match
      checker that I don't want to lose. Here are the changes:
        * Some key functions of the checker now have SCC annotations
        * Better `-ddump-ec-trace` diagnostics for easier debugging. I added
          'traceWhenFailPm' to see *why* a particular `MaybeT` computation fails and
          made use of it in `instCon`.
      I also increased the acceptance threshold of T11545, which seems to fail
      randomly lately due to ghc/max flukes.
    • Matthew Pickering's avatar
      hadrian: Use ghc version as suffix for all executables · 6af7d127
      Matthew Pickering authored
      [matt@nixos:~/ghc-unique-spin]$ ls _build/bindist/ghc-9.3.20210813-x86_64-unknown-linux/bin/
      ghc                             haddock                   runghc
      ghc-9.3.20210813                haddock-ghc-9.3.20210813  runghc-9.3.20210813
      ghc-iserv                       hp2ps                     runhaskell
      ghc-iserv-dyn                   hp2ps-ghc-9.3.20210813    runhaskell-9.3.20210813
      ghc-iserv-dyn-ghc-9.3.20210813  hpc                       unlit
      ghc-iserv-ghc-9.3.20210813      hpc-ghc-9.3.20210813      unlit-ghc-9.3.20210813
      ghc-pkg                         hsc2hs
      ghc-pkg-9.3.20210813            hsc2hs-ghc-9.3.20210813
      [matt@nixos:~/ghc-unique-spin]$ ls _build/bindist/ghc-9.3.20210813-x86_64-unknown-linux/wrappers/
      ghc                ghc-pkg-9.3.20210813      hpc                      runghc-9.3.20210813
      ghc-9.3.20210813   haddock                   hpc-ghc-9.3.20210813     runhaskell
      ghci               haddock-ghc-9.3.20210813  hsc2hs                   runhaskell-9.3.20210813
      ghci-9.3.20210813  hp2ps                     hsc2hs-ghc-9.3.20210813
      ghc-pkg            hp2ps-ghc-9.3.20210813    runghc
      See the discussion on #19571 where we decided that it was most sensible
      to use the same version number as a suffix for all executables. For
      those whose version number is different to normal (for example, haddock
      as it's own versioning scheme) the additional "ghc" suffix is used.
      Cabal already knows to look for this suffix so should work nicely with
      existing tooling.
    • Matthew Pickering's avatar
      hadrian: Write version wrappers in C rather than Haskell · 7dde84ad
      Matthew Pickering authored
      This reduces the resulting binary size on windows where the executables
      were statically linked.
    • Matthew Pickering's avatar
      hadrian: Include runhaskell in bindist · 27c27f7d
      Matthew Pickering authored
      Fixes #19571
      bin folder now containers/
      ghc                     ghc-iserv-dyn-9.3.20210813  hp2ps      hsc2hs-0.68.8            unlit
      ghc-9.3.20210813        ghc-pkg                     hp2ps-0.1  runghc                   unlit-0.1
      ghc-iserv               ghc-pkg-9.3.20210813        hpc        runghc-9.3.20210813
      ghc-iserv-9.3.20210813  haddock                     hpc-0.68   runhaskell
      ghc-iserv-dyn           haddock-2.24.0              hsc2hs     runhaskell-9.3.20210813
      which installed via wrappers looks like
      lrwxrwxrwx 1 matt users   16 Aug 13 17:32 ghc -> ghc-9.3.20210813
      -rwxr-xr-x 1 matt users  446 Aug 13 17:32 ghc-9.3.20210813
      lrwxrwxrwx 1 matt users   17 Aug 13 17:32 ghci -> ghci-9.3.20210813
      -rwxr-xr-x 1 matt users  480 Aug 13 17:32 ghci-9.3.20210813
      lrwxrwxrwx 1 matt users   20 Aug 13 17:32 ghc-pkg -> ghc-pkg-9.3.20210813
      -rwxr-xr-x 1 matt users  506 Aug 13 17:32 ghc-pkg-9.3.20210813
      lrwxrwxrwx 1 matt users   14 Aug 13 17:32 haddock -> haddock-2.24.0
      -rwxr-xr-x 1 matt users  454 Aug 13 17:32 haddock-2.24.0
      lrwxrwxrwx 1 matt users    9 Aug 13 17:32 hp2ps -> hp2ps-0.1
      -rwxr-xr-x 1 matt users  420 Aug 13 17:32 hp2ps-0.1
      lrwxrwxrwx 1 matt users    8 Aug 13 17:32 hpc -> hpc-0.68
      -rwxr-xr-x 1 matt users  418 Aug 13 17:32 hpc-0.68
      lrwxrwxrwx 1 matt users   13 Aug 13 17:32 hsc2hs -> hsc2hs-0.68.8
      -rwxr-xr-x 1 matt users 1.2K Aug 13 17:32 hsc2hs-0.68.8
      lrwxrwxrwx 1 matt users   19 Aug 13 17:32 runghc -> runghc-9.3.20210813
      -rwxr-xr-x 1 matt users  457 Aug 13 17:32 runghc-9.3.20210813
      lrwxrwxrwx 1 matt users   23 Aug 13 17:32 runhaskell -> runhaskell-9.3.20210813
      -rwxr-xr-x 1 matt users  465 Aug 13 17:32 runhaskell-9.3.20210813
    • Ben Gamari's avatar
      users guide: Document -hpcdir flag · 69fb6f6a
      Ben Gamari authored
      Previously this was undocumented.
  9. 19 Aug, 2021 4 commits
  10. 18 Aug, 2021 4 commits
    • sheaf's avatar
      Don't look for TypeError in type family arguments · 4a10f0ff
      sheaf authored
      Changes checkUserTypeError to no longer look for custom type errors
      inside type family arguments.
      This means that a program such as
      foo :: F xyz (TypeError (Text "blah")) -> bar
      does not throw a type error at definition site.
      This means that more programs can be accepted, as the custom type error
      might disappear upon reducing the above type family F.
      This applies only to user-written type signatures, which are checked
      within checkValidType. Custom type errors in type family arguments
      continue to be reported when they occur in unsolved Wanted constraints.
      Fixes #20241
    • Matthew Pickering's avatar
      recomp: Check backend type rather than -fwrite-interface to decide whether we need any objects · d9cf2ec8
      Matthew Pickering authored
      This was a small oversight in the original patch which leads to spurious
      recompilation when using `-fno-code` but not `-fwrite-interface`, which
      you plausibly might do when using ghci.
      Fixes #20216
    • Matthew Pickering's avatar
      Driver rework pt3: the upsweep · 5f0d2dab
      Matthew Pickering authored
      This patch specifies and simplifies the module cycle compilation
      in upsweep. How things work are described in the Note [Upsweep]
      Note [Upsweep]
      Upsweep takes a 'ModuleGraph' as input, computes a build plan and then executes
      the plan in order to compile the project.
      The first step is computing the build plan from a 'ModuleGraph'.
      The output of this step is a `[BuildPlan]`, which is a topologically sorted plan for
      how to build all the modules.
      data BuildPlan = SingleModule ModuleGraphNode  -- A simple, single module all alone but *might* have an hs-boot file which isn't part of a cycle
                     | ResolvedCycle [ModuleGraphNode]   -- A resolved cycle, linearised by hs-boot files
                     | UnresolvedCycle [ModuleGraphNode] -- An actual cycle, which wasn't resolved by hs-boot files
      The plan is computed in two steps:
      Step 1: Topologically sort the module graph without hs-boot files. This returns a [SCC ModuleGraphNode] which contains
      Step 2: For each cycle, topologically sort the modules in the cycle *with* the relevant hs-boot files. This should
              result in an acyclic build plan if the hs-boot files are sufficient to resolve the cycle.
      The `[BuildPlan]` is then interpreted by the `interpretBuildPlan` function.
      * `SingleModule nodes` are compiled normally by either the upsweep_inst or upsweep_mod functions.
      * `ResolvedCycles` need to compiled "together" so that the information which ends up in
        the interface files at the end is accurate (and doesn't contain temporary information from
        the hs-boot files.)
        - During the initial compilation, a `KnotVars` is created which stores an IORef TypeEnv for
          each module of the loop. These IORefs are gradually updated as the loop completes and provide
          the required laziness to typecheck the module loop.
        - At the end of typechecking, all the interface files are typechecked again in
          the retypecheck loop. This time, the knot-tying is done by the normal laziness
          based tying, so the environment is run without the KnotVars.
      * UnresolvedCycles are indicative of a proper cycle, unresolved by hs-boot files
        and are reported as an error to the user.
      The main trickiness of `interpretBuildPlan` is deciding which version of a dependency
      is visible from each module. For modules which are not in a cycle, there is just
      one version of a module, so that is always used. For modules in a cycle, there are two versions of
      1. Internal to loop: The version created whilst compiling the loop by upsweep_mod.
      2. External to loop: The knot-tied version created by typecheckLoop.
      Whilst compiling a module inside the loop, we need to use the (1). For a module which
      is outside of the loop which depends on something from in the loop, the (2) version
      is used.
      As the plan is interpreted, which version of a HomeModInfo is visible is updated
      by updating a map held in a state monad. So after a loop has finished being compiled,
      the visible module is the one created by typecheckLoop and the internal version is not
      used again.
      This plan also ensures the most important invariant to do with module loops:
      > If you depend on anything within a module loop, before you can use the dependency,
        the whole loop has to finish compiling.
      The end result of `interpretBuildPlan` is a `[MakeAction]`, which are pairs
      of `IO a` actions and a `MVar (Maybe a)`, somewhere to put the result of running
      the action. This list is topologically sorted, so can be run in order to compute
      the whole graph.
      As well as this `interpretBuildPlan` also outputs an `IO [Maybe (Maybe HomeModInfo)]` which
      can be queried at the end to get the result of all modules at the end, with their proper
      visibility. For example, if any module in a loop fails then all modules in that loop will
      report as failed because the visible node at the end will be the result of retypechecking
      those modules together.
      Along the way we also fix a number of other bugs in the driver:
      * Unify upsweep and parUpsweep.
      * Fix #19937 (static points, ghci and -j)
      * Adds lots of module loop tests due to Divam.
      Also related to #20030
      Co-authored-by: Divam Narula's avatarDivam Narula <dfordivam@gmail.com>
      Metric Decrease:
    • Matthew Pickering's avatar
      Fix parsing of rpaths which include spaces in runInjectRPaths · 0ba21dbe
      Matthew Pickering authored
      The logic didn't account for the fact that the paths could contain
      spaces before which led to errors such as the following from
      Stderr ( T14304 ):
      Warning: -rtsopts and -with-rtsopts have no effect with -shared.
          Call hs_init_ghc() from your main() function to set these options.
      error: /nix/store/a6j5761iy238pbckxq2xrhqr2d5kra4m-cctools-binutils-darwin-949.0.1/bin/install_name_tool: for: dist/build/libHSp-0.1-ghc8.10.6.dylib (for architecture arm64) option "-add_rpath /Users/matt/ghc/bindisttest/install   dir/lib/ghc-8.10.6/ghc-prim-0.6.1" would duplicate path, file already has LC_RPATH for: /Users/matt/ghc/bindisttest/install   dir/lib/ghc-8.10.6/ghc-prim-0.6.1
      `install_name_tool' failed in phase `Install Name Tool'. (Exit code: 1)
      Fixes #20212
      This apparently also fixes #20026, which is a nice surprise.
  11. 17 Aug, 2021 3 commits
    • Sylvain Henry's avatar
      StgToCmm: use correct bounds for switches on sized values · 5798357d
      Sylvain Henry authored
      StgToCmm was only using literals signedness to determine whether using
      Int and Word range in Cmm switches. Now that we have sized literals
      (Int8#, Int16#, etc.), it needs to take their ranges into account.
    • John Ericson's avatar
      Test non-native switch C-- with twos compliment · b784a51e
      John Ericson authored
      We don't want regressions like e8f7734d
      to regress.
      Co-Authored-By: default avatarSylvain Henry <hsyl20@gmail.com>
    • Matthew Pickering's avatar
      ghci: Fix rec statements in interactive prompt · acb188e0
      Matthew Pickering authored
      We desugar a recursive Stmt to somethign like
        (a,_,c) <- mfix (\(a,b,_) -> do { ... ; return (a,b,c) })
        ...stuff after the rec...
      The knot-tied tuple must contain
      * All the variables that are used before they are bound in the `rec` block
      * All the variables that are used after the entire `rec` block
      In the case of GHCi, however, we don't know what variables will be used
      after the `rec` (#20206).  For example, we might have
          ghci>  rec { x <- e1; y <- e2 }
          ghci>  print x
          ghci>  print y
      So we have to assume that *all* the variables bound in the `rec` are used
      afterwards.  We use `Nothing` in the argument to segmentRecStmts to signal
      that all the variables are used.
      Fixes #20206
  12. 15 Aug, 2021 3 commits
    • Greg Steuck's avatar
      Fix iconv detection in configure on OpenBSD · 31dc013f
      Greg Steuck authored
      This regressed in 544414ba causing
      configure: error: iconv is required on non-Windows platforms
      More details:
    • Simon Peyton Jones's avatar
      Use the right InScopeSet for findBest · 7f217429
      Simon Peyton Jones authored
      This is the right thing to do, easy to do, and fixes
      a second not-in-scope crash in #20200 (see !6302)
      The problem occurs in the findBest test, which compares
      two RULES.
      Repro case in simplCore/should_compile/T20200a
    • Krzysztof Gogolewski's avatar
      Fix lookupIdSubst call during RULE matching · 149bce42
      Krzysztof Gogolewski authored
      As #20200 showed, there was a call to lookupIdSubst during RULE
      matching, where the variable being looked up wasn't in the InScopeSet.
      This patch fixes the problem at source, by dealing separately with
      nested and non-nested binders.
      As a result we can change the trace call in lookupIdSubst to a
      proper panic -- if it happens, we really want to know.