1. 26 Nov, 2021 6 commits
  2. 25 Nov, 2021 17 commits
    • Ben Gamari's avatar
      compiler: Mark GHC.Prelude as Haddock no-home · cafb1f99
      Ben Gamari authored
      This significantly improves Haddock documentation generated by nix.
    • sheaf's avatar
      Allow boring class declarations in hs-boot files · f27a63fe
      sheaf authored
        There are two different ways of declaring a class in an hs-boot file:
          - a full declaration, where everything is written as it is
            in the .hs file,
          - an abstract declaration, where class methods and superclasses
            are left out.
        However, a declaration with no methods and a trivial superclass,
        such as:
          class () => C a
        was erroneously considered to be an abstract declaration, because
        the superclass is trivial.
        This is remedied by a one line fix in GHC.Tc.TyCl.tcClassDecl1.
        This patch also further clarifies the documentation around
        class declarations in hs-boot files.
        Fixes #20661, #20588.
    • Gergő Érdi's avatar
      Add `llvmOptLevel` to `DynFlags` (#20500) · b52a9a3f
      Gergő Érdi authored
    • Gergő Érdi's avatar
    • Gergő Érdi's avatar
    • Gergő Érdi's avatar
    • Roland Senn's avatar
      GHCi Debugger - Improve RTTI · b24e8d91
      Roland Senn authored
      When processing the heap, use also `APClosures` to create additional type
      constraints. This adds more equations and therefore improves the unification
      process to infer the correct type of values at breakpoints.
      (Fix the `incr` part of #19559)
    • Pepe Iborra's avatar
      drop instance Semigroup InstalledModuleEnv · b742475a
      Pepe Iborra authored
      Instead, introduce plusInstalledModuleEnv
    • Pepe Iborra's avatar
      Drop instance Semigroup ModuleEnv · 47f36440
      Pepe Iborra authored
      There is more than one possible Semigroup and it is not needed since plusModuleEnv can be used directly
    • Pepe Iborra's avatar
      Monoid instance for InstalledModuleEnv · 52cdc2fe
      Pepe Iborra authored
    • Matthew Pickering's avatar
      Don't use implicit lifting when deriving Lift · 4d34bf15
      Matthew Pickering authored
      It isn't much more complicated to be more precise when deriving Lift so
      we now generate
      data Foo = Foo Int Bool
      instance Lift Foo where
        lift (Foo a b) = [| Foo $(lift a) $(lift b) |]
        liftTyped (Foo a b) = [|| Foo $$(lift a) $$(lift b) |]
      This fixes #20688 which complained about using implicit lifting in the
      derived code.
    • Krzysztof Gogolewski's avatar
      Misc cleanup · e33412d0
      Krzysztof Gogolewski authored
      * Remove `getTag_RDR` (unused), `tidyKind` and `tidyOpenKind`
        (already available as `tidyType` and `tidyOpenType`)
      * Remove Note [Explicit Case Statement for Specificity].
        Since 0a709dd9 we require GHC 8.10 for bootstrapping.
      * Change the warning to `cmpAltCon` to a panic.
        This shouldn't happen.  If it ever does, the code was wrong anyway:
        it shouldn't always return `LT`, but rather `LT` in one case
        and `GT` in the other case.
      * Rename `verifyLinearConstructors` to `verifyLinearFields`
      * Fix `Note [Local record selectors]` which was not referenced
      * Remove vestiges of `type +v`
      * Minor fixes to StaticPointers documentation, part of #15603
    • CarrieMY's avatar
      Enable UnboxedTuples in `genInst`, Fixes #20524 · 7c65687e
      CarrieMY authored
    • Christiaan Baaij's avatar
      Compare types of recursive let-bindings in alpha-equivalence · 3639ad8f
      Christiaan Baaij authored
      This commit fixes #20641 by checking the types of recursive
      let-bindings when performing alpha-equality.
      The `Eq (DeBruijn CoreExpr)` instance now also compares
      `BreakPoint`s similarly to `GHC.Core.Utils.eqTickish`, taking
      bound variables into account.
      In addition, the `Eq (DeBruijn Type)` instance now correctly
      compares the kinds of the types when one of them contains a
      Cast: the instance is modeled after `nonDetCmpTypeX`.
    • Christiaan Baaij's avatar
      Ensure new Ct/evidence invariant · e3c59191
      Christiaan Baaij authored
      The `ctev_pred` field of a `CtEvidence` is a just a cache for the type
      of the evidence.  More precisely:
      * For Givens, `ctev_pred` = `varType ctev_evar`
      * For Wanteds, `ctev_pred` = `evDestType ctev_dest`
      This new invariant is needed because evidence can become part of a
      type, via `Castty ty kco`.
    • Matthew Pickering's avatar
      Revert "Convert lookupIdSubst panic back to a warning (#20200)" · 6907e9fa
      Matthew Pickering authored
      This reverts commit df1d808f.
    • Matthew Pickering's avatar
      Correct retypechecking in --make mode · 91c0a657
      Matthew Pickering authored
      Note [Hydrating Modules]
      What is hydrating a module?
      * There are two versions of a module, the ModIface is the on-disk version and the ModDetails is a fleshed-out in-memory version.
      * We can **hydrate** a ModIface in order to obtain a ModDetails.
      Hydration happens in three different places
      * When an interface file is initially loaded from disk, it has to be hydrated.
      * When a module is finished compiling, we hydrate the ModIface in order to generate
        the version of ModDetails which exists in memory (see Note)
      * When dealing with boot files and module loops (see Note [Rehydrating Modules])
      Note [Rehydrating Modules]
      If a module has a boot file then it is critical to rehydrate the modules on
      the path between the two.
      Suppose we have ("R" for "recursive"):
      R.hs-boot:   module R where
                     data T
                     g :: T -> T
      A.hs:        module A( f, T, g ) where
                      import {-# SOURCE #-} R
                      data S = MkS T
                      f :: T -> S = ...g...
      R.hs:        module R where
                      data T = T1 | T2 S
                      g = ...f...
      After compiling A.hs we'll have a TypeEnv in which the Id for `f` has a type
      type uses the AbstractTyCon T; and a TyCon for `S` that also mentions that same
      AbstractTyCon. (Abstract because it came from R.hs-boot; we know nothing about
      When compiling R.hs, we build a TyCon for `T`.  But that TyCon mentions `S`, and
      it currently has an AbstractTyCon for `T` inside it.  But we want to build a
      fully cyclic structure, in which `S` refers to `T` and `T` refers to `S`.
      Solution: **rehydration**.  *Before compiling `R.hs`*, rehydrate all the
      ModIfaces below it that depend on R.hs-boot.  To rehydrate a ModIface, call
      `typecheckIface` to convert it to a ModDetails.  It's just a de-serialisation
      step, no type inference, just lookups.
      Now `S` will be bound to a thunk that, when forced, will "see" the final binding
      for `T`; see [Tying the knot](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/tying-the-knot).
      But note that this must be done *before* compiling R.hs.
      When compiling R.hs, the knot-tying stuff above will ensure that `f`'s unfolding
      mentions the `LocalId` for `g`.  But when we finish R, we carefully ensure that
      all those `LocalIds` are turned into completed `GlobalIds`, replete with
      unfoldings etc.   Alas, that will not apply to the occurrences of `g` in `f`'s
      unfolding. And if we leave matters like that, they will stay that way, and *all*
      subsequent modules that import A will see a crippled unfolding for `f`.
      Solution: rehydrate both R and A's ModIface together, right after completing R.hs.
      We only need rehydrate modules that are
      * Below R.hs
      * Above R.hs-boot
      There might be many unrelated modules (in the home package) that don't need to be
      This dark corner is the subject of #14092.
      Suppose we add to our example
      X.hs     module X where
                 import A
                 data XT = MkX T
                 fx = ...g...
      If in `--make` we compile R.hs-boot, then A.hs, then X.hs, we'll get a `ModDetails` for `X` that has an AbstractTyCon for `T` in the the argument type of `MkX`.  So:
      * Either we should delay compiling X until after R has beeen compiled.
      * Or we should rehydrate X after compiling R -- because it transitively depends on R.hs-boot.
      Ticket #20200 has exposed some issues to do with the knot-tying logic in GHC.Make, in `--make` mode.
      this particular issue starts [here](#20200 (comment 385758)).
      The wiki page [Tying the knot](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/tying-the-knot) is helpful.
      Also closely related are
          * #14092
          * #14103
      Fixes tickets #20200 #20561
  3. 24 Nov, 2021 1 commit
    • Alex D's avatar
      Combine STG free variable traversals (#17978) · 16690374
      Alex D authored
      Previously we would traverse the STG AST twice looking for free variables.
       * Once in `annTopBindingsDeps` which considers top level and imported ids free.
         Its output is used to put bindings in dependency order. The pass happens
         in STG pipeline.
       * Once in `annTopBindingsFreeVars` which only considers non-top level ids free.
         Its output is used by the code generator to compute offsets into closures.
         This happens in Cmm (CodeGen) pipeline.
      Now these two traversal operations are merged into one - `FVs.depSortWithAnnotStgPgm`.
      The pass happens right at the end of STG pipeline. Some type signatures had to be
      updated due to slight shifts of StgPass boundaries (for example, top-level CodeGen
      handler now directly works with CodeGen flavoured Stg AST instead of Vanilla).
      Due to changed order of bindings, a few debugger type reconstruction bugs
      have resurfaced again (see tests break018, break021) - work item #18004 tracks this
      authors: simonpj, nineonine
  4. 23 Nov, 2021 2 commits
    • Krzysztof Gogolewski's avatar
      Add a warning for GADT match + NoMonoLocalBinds (#20485) · 3ab3631f
      Krzysztof Gogolewski authored
      Previously, it was an error to pattern match on a GADT
      without GADTs or TypeFamilies.
      This is now allowed. Instead, we check the flag MonoLocalBinds;
      if it is not enabled, we issue a warning, controlled by -Wgadt-mono-local-binds.
      Also fixes #20485: pattern synonyms are now checked too.
    • Andreas Klebinger's avatar
      CmmSink: Be more aggressive in removing no-op assignments. · 680ef2c8
      Andreas Klebinger authored
      No-op assignments like R1 = R1 are not only wasteful. They can also
      inhibit other optimizations like inlining assignments that read from
      We now check for assignments being a no-op before and after we
      simplify the RHS in Cmm sink which should eliminate most of these
  5. 22 Nov, 2021 1 commit
    • Simon Peyton Jones's avatar
      Better wrapper activation calculation · f748988b
      Simon Peyton Jones authored
      As #20709 showed, GHC could prioritise a wrapper over a SPEC
      rule, which is potentially very bad.  This patch fixes that
      The fix is is described in Note [Wrapper activation], especially
      item 4, 4a, and Conclusion.
      For now, it has a temporary hack (replicating what was there before
      to make sure that wrappers inline no earlier than phase 2.  But
      it should be temporary; see #19001.
  6. 20 Nov, 2021 4 commits
    • sheaf's avatar
      Include "not more specific" info in overlap msg · 742d8b60
      sheaf authored
        When instances overlap, we now include additional information
        about why we weren't able to select an instance: perhaps
        one instance overlapped another but was not strictly more specific,
        so we aren't able to directly choose it.
      Fixes #20542
    • Zubin's avatar
      Use 'NonEmpty' for the fields in an 'HsProjection' (#20389) · bc7e9f03
      Zubin authored
      T12545 is very inconsistently affected by this change for some reason.
      There is a decrease in allocations on most configurations, but
      an increase on validate-x86_64-linux-deb9-unreg-hadrian. Accepting it
      as it seems unrelated to this patch.
      Metric Decrease:
      Metric Increase:
    • Sylvain Henry's avatar
      More support for optional home-unit · bdeea37e
      Sylvain Henry authored
      This is a preliminary refactoring for #14335 (supporting plugins in
      cross-compilers). In many places the home-unit must be optional because
      there won't be one available in the plugin environment (we won't be
      compiling anything in this environment). Hence we replace "HomeUnit"
      with "Maybe HomeUnit" in a few places and we avoid the use of
      "hsc_home_unit" (which is partial) in some few others.
    • Matthew Pickering's avatar
      Remove unused module import syntax from .bkp mode · 3d6b78db
      Matthew Pickering authored
      .bkp mode had this unused feature where you could write
        module A
      and it would go looking for A.hs on the file system and use that rather
      than provide the definition inline.
      This isn't use anywhere in the testsuite and the code to find the module
      A looks dubious. Therefore to reduce .bkp complexity I propose to remove
      Fixes #20701
  7. 18 Nov, 2021 1 commit
    • Simon Peyton Jones's avatar
      Add one line of comments (c.f. !5706) · f55ae180
      Simon Peyton Jones authored
      Ticket #19815 suggested changing coToMCo to use
      isReflexiveCo rather than isReflCo.  But perf results
      weren't encouraging. This patch just adds a comment to
      point to the data, such as it is.
  8. 17 Nov, 2021 3 commits
    • MorrowM's avatar
      Improve handling of import statements in GHCi (#20473) · 7850142c
      MorrowM authored
      Currently in GHCi, when given a line of user input we:
      1. Attempt to parse and handle it as a statement
      2. Otherwise, attempt to parse and handle a single import
      3. Otherwise, check if there are imports present (and if so display an error message)
      4. Otherwise, attempt to parse a module and only handle the declarations
      This patch simplifies the process to:
      Attempt to parse and handle it as a statement
      Otherwise, attempt to parse a module and handle the imports and declarations
      This means that multiple imports in a multiline are now accepted, and a multiline containing both imports and declarations is now accepted (as well as when separated by semicolons).
    • Sebastian Graf's avatar
      Pmc: Don't case split on wildcard matches (#20642) · 29086749
      Sebastian Graf authored
      Since 8.10, when formatting a pattern match warning, we'd case split on a
      wildcard match such as
      foo :: [a] -> [a]
      foo [] = []
      foo xs = ys
        (_, ys@(_:_)) = splitAt 0 xs
      -- Pattern match(es) are non-exhaustive
      -- In a pattern binding:
      --     Patterns not matched:
      --         ([], [])
      --         ((_:_), [])
      But that's quite verbose and distracts from which part of the pattern was
      actually the inexhaustive one. We'd prefer a wildcard for the first pair
      component here, like it used to be in GHC 8.8.
      On the other hand, case splitting is pretty handy for `-XEmptyCase` to know the
      different constructors we could've matched on:
      f :: Bool -> ()
      f x = case x of {}
      -- Pattern match(es) are non-exhaustive
      -- In a pattern binding:
      --     Patterns not matched:
      --         False
      --         True
      The solution is to communicate that we want a top-level case split to
      `generateInhabitingPatterns` for `-XEmptyCase`, which is exactly what
      this patch arranges. Details in `Note [Case split inhabiting patterns]`.
      Fixes #20642.
    • Ben Gamari's avatar
      Increase type sharing · 083a7583
      Ben Gamari authored
      Fixes #20541 by making mkTyConApp do more sharing of types.
      In particular, replace
      * BoxedRep Lifted    ==>  LiftedRep
      * BoxedRep Unlifted  ==>  UnliftedRep
      * TupleRep '[]       ==>  ZeroBitRep
      * TYPE ZeroBitRep    ==>  ZeroBitType
      In each case, the thing on the right is a type synonym
      for the thing on the left, declared in ghc-prim:GHC.Types.
      See Note [Using synonyms to compress types] in GHC.Core.Type.
      The synonyms for ZeroBitRep and ZeroBitType are new, but absolutely
      in the same spirit as the other ones.   (These synonyms are mainly
      for internal use, though the programmer can use them too.)
      I also renamed GHC.Core.Ty.Rep.isVoidTy to isZeroBitTy, to be
      compatible with the "zero-bit" nomenclature above.  See discussion
      on !6806.
      There is a tricky wrinkle: see GHC.Core.Types
        Note [Care using synonyms to compress types]
      Compiler allocation decreases by up to 0.8%.
  9. 15 Nov, 2021 4 commits
    • Sylvain Henry's avatar
      Fix windres invocation · 3302f42a
      Sylvain Henry authored
      I've already fixed this 7 months ago in the comments of #16780 but it
      never got merged. Now we need this for #20657 too.
    • Ryan Scott's avatar
      Instantiate field types properly in stock-derived instances · 3e5f0595
      Ryan Scott authored
      Previously, the `deriving` machinery was very loosey-goosey about how it used
      the types of data constructor fields when generating code. It would usually
      just consult `dataConOrigArgTys`, which returns the _uninstantiated_ field
      types of each data constructor. Usually, you can get away with this, but
      issues #20375 and #20387 revealed circumstances where this approach fails.
      Instead, when generated code for a stock-derived instance
      `C (T arg_1 ... arg_n)`, one must take care to instantiate the field types of
      each data constructor with `arg_1 ... arg_n`. The particulars of how this is
      accomplished is described in the new
      `Note [Instantiating field types in stock deriving]` in
      `GHC.Tc.Deriv.Generate`. Some highlights:
      * `DerivInstTys` now has a new `dit_dc_inst_arg_env :: DataConEnv [Type]`
        field that caches the instantiated field types of each data constructor.
        Whenever we need to consult the field types somewhere in `GHC.Tc.Deriv.*`
        we avoid using `dataConOrigArgTys` and instead look it up in
      * Because `DerivInstTys` now stores the instantiated field types of each
        constructor, some of the details of the `GHC.Tc.Deriv.Generics.mkBindsRep`
        function were able to be simplified. In particular, we no longer need to
        apply a substitution to instantiate the field types in a `Rep(1)` instance,
        as that is already done for us by `DerivInstTys`. We still need a
        substitution to implement the "wrinkle" section of
        `Note [Generating a correctly typed Rep instance]`, but the code is
        nevertheless much simpler than before.
      * The `tyConInstArgTys` function has been removed in favor of the new
        `GHC.Core.DataCon.dataConInstUnivs` function, which is really the proper tool
        for the job. `dataConInstUnivs` is much like `tyConInstArgTys` except that it
        takes a data constructor, not a type constructor, as an argument, and it adds
        extra universal type variables from that data constructor at the end of the
        returned list if need be. `dataConInstUnivs` takes care to instantiate the
        kinds of the universal type variables at the end, thereby avoiding a bug in
        `tyConInstArgTys` discovered in
        #20387 (comment 377037).
      Fixes #20375. Fixes #20387.
    • Ryan Scott's avatar
      Refactoring: Move DataConEnv to GHC.Core.DataCon · 564a19af
      Ryan Scott authored
      `DataConEnv` will prove to be useful in another place besides
      `GHC.Core.Opt.SpecConstr` in a follow-up commit.
    • Ryan Scott's avatar
      Refactoring: Consolidate some arguments with DerivInstTys · aa372972
      Ryan Scott authored
      Various functions in GHC.Tc.Deriv.* were passing around `TyCon`s and
      `[Type]`s that ultimately come from the same `DerivInstTys`. This patch
      moves the definition of `DerivInstTys` to `GHC.Tc.Deriv.Generate` so that
      all of these `TyCon` and `[Type]` arguments can be consolidated into a
      single `DerivInstTys`. Not only does this make the code easier to read
      (in my opinion), this will also be important in a subsequent commit where we
      need to add another field to `DerivInstTys` that will also be used from
      `GHC.Tc.Deriv.Generate` and friends.
  10. 13 Nov, 2021 1 commit