1. 21 Nov, 2020 8 commits
  2. 20 Nov, 2020 9 commits
  3. 19 Nov, 2020 1 commit
    • Sebastian Graf's avatar
      PmCheck: Print types of uncovered patterns (#18932) · 8150f654
      Sebastian Graf authored
      In order to avoid confusion as in #18932, we display the type of the
      match variables in the non-exhaustiveness warning, e.g.
      T18932.hs:14:1: warning: [-Wincomplete-patterns]
          Pattern match(es) are non-exhaustive
          In an equation for ‘g’:
              Patterns of type  ‘T a’, ‘T a’, ‘T a’ not matched:
                  (MkT2 _) (MkT1 _) (MkT1 _)
                  (MkT2 _) (MkT1 _) (MkT2 _)
                  (MkT2 _) (MkT2 _) (MkT1 _)
                  (MkT2 _) (MkT2 _) (MkT2 _)
      14 | g (MkT1 x) (MkT1 _) (MkT1 _) = x
         | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      It also allows us to omit the type signature on wildcard matches which
      we previously showed in only some situations, particularly
      Fixes #18932.
  4. 16 Nov, 2020 1 commit
  5. 15 Nov, 2020 8 commits
    • Ben Gamari's avatar
      ghc-bin: Build with eventlogging by default · fc644b1a
      Ben Gamari authored
      We now have all sorts of great facilities using the
      eventlog which were previously unavailable without
      building a custom GHC. Fix this by linking with
      `-eventlog` by default.
    • Moritz Angermann's avatar
      AArch64/arm64 adjustments · 8887102f
      Moritz Angermann authored
      This addes the necessary logic to support aarch64 on elf, as well
      as aarch64 on mach-o, which Apple calls arm64.
      We change architecture name to AArch64, which is the official arm
      naming scheme.
    • Ryan Scott's avatar
      Use tcSplitForAllInvisTyVars (not tcSplitForAllTyVars) in more places · 645444af
      Ryan Scott authored
      The use of `tcSplitForAllTyVars` in `tcDataFamInstHeader` was the immediate
      cause of #18939, and replacing it with a new `tcSplitForAllInvisTyVars`
      function (which behaves like `tcSplitForAllTyVars` but only splits invisible
      type variables) fixes the issue. However, this led me to realize that _most_
      uses of `tcSplitForAllTyVars` in GHC really ought to be
      `tcSplitForAllInvisTyVars` instead. While I was in town, I opted to replace
      most uses of `tcSplitForAllTys` with `tcSplitForAllTysInvis` to reduce the
      likelihood of such bugs in the future.
      I say "most uses" above since there is one notable place where we _do_ want
      to use `tcSplitForAllTyVars`: in `GHC.Tc.Validity.forAllTyErr`, which produces
      the "`Illegal polymorphic type`" error message if you try to use a higher-rank
      `forall` without having `RankNTypes` enabled. Here, we really do want to split
      all `forall`s, not just invisible ones, or we run the risk of giving an
      inaccurate error message in the newly added `T18939_Fail` test case.
      I debated at some length whether I wanted to name the new function
      `tcSplitForAllInvisTyVars` or `tcSplitForAllTyVarsInvisible`, but in the end,
      I decided that I liked the former better. For consistency's sake, I opted to
      rename the existing `splitPiTysInvisible` and `splitPiTysInvisibleN` functions
      to `splitInvisPiTys` and `splitPiTysInvisN`, respectively, so that they use the
      same naming convention. As a consequence, this ended up requiring a `haddock`
      submodule bump.
      Fixes #18939.
    • Ryan Scott's avatar
      Name (tc)SplitForAll- functions more consistently · d61adb3d
      Ryan Scott authored
      There is a zoo of `splitForAll-` functions in `GHC.Core.Type` (as well as
      `tcSplitForAll-` functions in `GHC.Tc.Utils.TcType`) that all do very similar
      things, but vary in the particular form of type variable that they return. To
      make things worse, the names of these functions are often quite misleading.
      Some particularly egregious examples:
      * `splitForAllTys` returns `TyCoVar`s, but `splitSomeForAllTys` returns
      * `splitSomeForAllTys` returns `VarBndr`s, but `tcSplitSomeForAllTys` returns
      * `splitForAllTys` returns `TyCoVar`s, but `splitForAllTysInvis` returns
        `InvisTVBinder`s. (This in particular arose in the context of #18939, and
        this finally motivated me to bite the bullet and improve the status quo
        vis-à-vis how we name these functions.)
      In an attempt to bring some sanity to how these functions are named, I have
      opted to rename most of these functions en masse to use consistent suffixes
      that describe the particular form of type variable that each function returns.
      In concrete terms, this amounts to:
      * Functions that return a `TyVar` now use the suffix `-TyVar`.
        This caused the following functions to be renamed:
        * `splitTyVarForAllTys` -> `splitForAllTyVars`
        * `splitForAllTy_ty_maybe` -> `splitForAllTyVar_maybe`
        * `tcSplitForAllTys` -> `tcSplitForAllTyVars`
        * `tcSplitSomeForAllTys` -> `tcSplitSomeForAllTyVars`
      * Functions that return a `CoVar` now use the suffix `-CoVar`.
        This caused the following functions to be renamed:
        * `splitForAllTy_co_maybe` -> `splitForAllCoVar_maybe`
      * Functions that return a `TyCoVar` now use the suffix `-TyCoVar`.
        This caused the following functions to be renamed:
        * `splitForAllTy` -> `splitForAllTyCoVar`
        * `splitForAllTys` -> `splitForAllTyCoVars`
        * `splitForAllTys'` -> `splitForAllTyCoVars'`
        * `splitForAllTy_maybe` -> `splitForAllTyCoVar_maybe`
      * Functions that return a `VarBndr` now use the suffix corresponding to the
        most relevant type synonym. This caused the following functions to be renamed:
        * `splitForAllVarBndrs` -> `splitForAllTyCoVarBinders`
        * `splitForAllTysInvis` -> `splitForAllInvisTVBinders`
        * `splitForAllTysReq` -> `splitForAllReqTVBinders`
        * `splitSomeForAllTys` -> `splitSomeForAllTyCoVarBndrs`
        * `tcSplitForAllVarBndrs` -> `tcSplitForAllTyVarBinders`
        * `tcSplitForAllTysInvis` -> `tcSplitForAllInvisTVBinders`
        * `tcSplitForAllTysReq` -> `tcSplitForAllReqTVBinders`
        * `tcSplitForAllTy_maybe` -> `tcSplitForAllTyVarBinder_maybe`
      Note that I left the following functions alone:
      * Functions that split apart things besides `ForAllTy`s, such as `splitFunTys`
        or `splitPiTys`. Thankfully, there are far fewer of these functions than
        there are functions that split apart `ForAllTy`s, so there isn't much of a
        pressing need to apply the new naming convention elsewhere.
      * Functions that split apart `ForAllCo`s in `Coercion`s, such as
        `GHC.Core.Coercion.splitForAllCo_maybe`. We could theoretically apply the new
        naming convention here, but then we'd have to figure out how to disambiguate
        `Type`-splitting functions from `Coercion`-splitting functions. Ultimately,
        the `Coercion`-splitting functions aren't used nearly as much as the
        `Type`-splitting functions, so I decided to leave the former alone.
      This is purely refactoring and should cause no change in behavior.
    • Ben Gamari's avatar
    • Ben Gamari's avatar
    • Ben Gamari's avatar
      nativeGen/dwarf: Only produce DW_AT_source_note DIEs in -g3 · 1e19183d
      Ben Gamari authored
      Standard debugging tools don't know how to understand these so let's not
      produce them unless asked.
    • Ben Gamari's avatar
      nativeGen/dwarf: Fix procedure end addresses · 0a7e592c
      Ben Gamari authored
      Previously the `.debug_aranges` and `.debug_info` (DIE) DWARF
      information would claim that procedures (represented with a
      `DW_TAG_subprogram` DIE) would only span the range covered by their entry
      block. This omitted all of the continuation blocks (represented by
      `DW_TAG_lexical_block` DIEs), confusing `perf`. Fix this by introducing
      a end-of-procedure label and using this as the `DW_AT_high_pc` of
      procedure `DW_TAG_subprogram` DIEs
      Fixes #17605.
  6. 13 Nov, 2020 4 commits
  7. 12 Nov, 2020 2 commits
  8. 11 Nov, 2020 7 commits
    • Krzysztof Gogolewski's avatar
    • GHC GitLab CI's avatar
      Introduce test for dynamic library unloading · e9e1b2e7
      GHC GitLab CI authored
      This uses the highMemDynamic flag introduced earlier to verify that
      dynamic objects are properly unloaded.
    • GHC GitLab CI's avatar
      rts: Introduce highMemDynamic · 7a65f9e1
      GHC GitLab CI authored
    • Ray Shih's avatar
      Add loadNativeObj and unloadNativeObj · 2782487f
      Ray Shih authored
      (This change is originally written by niteria)
      This adds two functions:
      * `loadNativeObj`
      * `unloadNativeObj`
      and implements them for Linux.
      They are useful if you want to load a shared object with Haskell code
      using the system linker and have GHC call dlclose() after the
      code is no longer referenced from the heap.
      Using the system linker allows you to load the shared object
      above outside the low-mem region. It also loads the DWARF sections
      in a way that `perf` understands.
      `dl_iterate_phdr` is what makes this implementation Linux specific.
    • Ömer Sinan Ağacan's avatar
      Fix and enable object unloading in GHCi · c34a4b98
      Ömer Sinan Ağacan authored
      Fixes #16525 by tracking dependencies between object file symbols and
      marking symbol liveness during garbage collection
      See Note [Object unloading] in CheckUnload.c for details.
    • Ben Gamari's avatar
      Enable -fexpose-internal-symbols when debug level >=2 · 584058dd
      Ben Gamari authored
      This seems like a reasonable default as the object file size increases
      by around 5%.
    • Ben Gamari's avatar
      codeGen: Produce local symbols for module-internal functions · c6264a2d
      Ben Gamari authored
      It turns out that some important native debugging/profiling tools (e.g.
      perf) rely only on symbol tables for function name resolution (as
      opposed to using DWARF DIEs). However, previously GHC would emit
      temporary symbols (e.g. `.La42b`) to identify module-internal
      entities. Such symbols are dropped during linking and therefore not
      visible to runtime tools (in addition to having rather un-helpful unique
      names). For instance, `perf report` would often end up attributing all
      cost to the libc `frame_dummy` symbol since Haskell code was no covered
      by any proper symbol (see #17605).
      We now rather follow the model of C compilers and emit
      descriptively-named local symbols for module internal things. Since this
      will increase object file size this behavior can be disabled with the
      `-fno-expose-internal-symbols` flag.
      With this `perf record` can finally be used against Haskell executables.
      Even more, with `-g3` `perf annotate` provides inline source code.