1. 22 Nov, 2020 7 commits
  2. 21 Nov, 2020 9 commits
  3. 20 Nov, 2020 9 commits
  4. 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.
  5. 16 Nov, 2020 1 commit
  6. 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.
  7. 13 Nov, 2020 4 commits
  8. 12 Nov, 2020 1 commit
    • Ben Gamari's avatar
      compiler: Fix recompilation checking · 5353fd50
      Ben Gamari authored
      In ticket #18733 we noticed a rather serious deficiency in the current
      fingerprinting logic for recursive groups. I have described the old
      fingerprinting story and its problems in Note [Fingerprinting recursive
      groups] and have reworked the story accordingly to avoid these issues.
      Fixes #18733.