1. 07 Sep, 2021 7 commits
    • Jens Petersen's avatar
      base Data.Fixed: fix documentation typo: succ (0.000 :: Milli) /= 1.001 · 3492a09e
      Jens Petersen authored
      ie `succ (0000) == 0001` -- (not 1001)
    • Ben Gamari's avatar
      gitlab-ci: Fix bash version-dependence in ci.sh · 2735f5a6
      Ben Gamari authored
      As described in https://stackoverflow.com/questions/7577052,
      safely expanding bash arrays is very-nearly impossible. The previous
      incantation failed under the bash version shipped with Centos 7.
    • Ben Gamari's avatar
      hadrian: Ensure that settings is regenerated during bindist installation · 81975ef3
      Ben Gamari authored
      Previously Hadrian would simply install the settings file generated in
      the build environment during the binary distribution installation. This
      is wrong since these environments may differ (e.g. different `cc`
      We noticed on Darwin when installation of a binary distribution produced
      on a newer Darwin release resulted in a broken compiler due to the
      installed `settings` file incorrectly claiming that `cc` supported
      Fixing this sadly requires a bit of code duplication since `settings` is
      produced by Hadrian and not `configure`. For now I have simply
      duplicated the `settings` generation logic used by the Make build system
      into Hadrian's bindist Makefile.
      Ultimately the solution will probably involve shipping a freestanding
      utility to replace `configure`'s toolchain probing logic and generate a
      toolchain description file (similar to `settings`) as described
      in #19877.
      Fixes #20253.
    • Sylvain Henry's avatar
      Bignum: refactor conversion rules · f72aa31d
      Sylvain Henry authored
      * make "passthrough" rules non built-in: they don't need to
      * enhance note about efficient conversions between numeric types
      * make integerFromNatural a little more efficient
      * fix noinline pragma for naturalToWordClamp# (at least with non
        built-in rules, we get warnings in cases like this)
    • Sylvain Henry's avatar
      GHCi: don't discard plugins on reload (#20335) · 3fb1afea
      Sylvain Henry authored
      Fix regression introduced in ecfd0278
    • Oleg Grenrus's avatar
      Define returnA = id · 89820293
      Oleg Grenrus authored
    • Alan Zimmerman's avatar
      EPA: order of semicolons and comments for top-level decls is wrong · 407d3b3a
      Alan Zimmerman authored
      A comment followed by a semicolon at the top level resulted in the
      preceding comments being attached to the following declaration.
      Capture the comments as belonging to the declaration preceding the
      semicolon instead.
      Closes #20258
  2. 06 Sep, 2021 1 commit
  3. 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.
  4. 28 Aug, 2021 3 commits
  5. 27 Aug, 2021 2 commits
  6. 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.
  7. 25 Aug, 2021 1 commit
  8. 24 Aug, 2021 7 commits
  9. 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.
  10. 19 Aug, 2021 4 commits
  11. 18 Aug, 2021 3 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: