1. 04 Jan, 2020 1 commit
  2. 09 Oct, 2019 1 commit
  3. 01 Oct, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Refactor iface file generation: · f3cb8c7c
      Ömer Sinan Ağacan authored
      This commit refactors interface file generation to allow information
      from the later passed (NCG, STG) to be stored in interface files.
      
      We achieve this by splitting interface file generation into two parts:
      * Partial interfaces, built based on the result of the core pipeline
      * A fully instantiated interface, which also contains the final
      fingerprints and can optionally contain information produced by the backend.
      
      This change is required by !1304 and !1530.
      
      -dynamic-too handling is refactored too: previously when generating code
      we'd branch on -dynamic-too *before* code generation, but now we do it
      after.
      
      (Original code written by @AndreasK in !1530)
      
      Performance
      ~~~~~~~~~~~
      
      Before this patch interface files where created and immediately flushed
      to disk which made space leaks impossible.
      With this change we instead use NFData to force all iface related data
      structures to avoid space leaks.
      
      In the process of refactoring it was discovered that the code in the
      ToIface Module allocated a lot of thunks which were immediately forced
      when writing/forcing the interface file. So we made this module more
      strict to avoid creating many of those thunks.
      
      Bottom line is that allocations go down by about ~0.1% compared to
      master.
      Residency is not meaningfully different after this patch.
      Runtime was not benchmarked.
      Co-Authored-By: Andreas Klebinger's avatarAndreas Klebinger <klebinger.andreas@gmx.at>
      Co-Authored-By: Ömer Sinan Ağacan's avatarÖmer Sinan Ağacan <omer@well-typed.com>
      f3cb8c7c
  4. 09 Sep, 2019 2 commits
    • Daniel Gröber (dxld)'s avatar
      Update FastString docstrings · f5e2fde4
      Daniel Gröber (dxld) authored
      1) FastStrings are always UTF-8 encoded now.
      2) Clarify what is meant by "hashed"
      3) Add mention of lazy z-enc
      f5e2fde4
    • Daniel Gröber (dxld)'s avatar
      Use lazyness for FastString's z-encoding memoization · 4cf91d1a
      Daniel Gröber (dxld) authored
      Having an IORef in FastString to memoize the z-encoded version is
      unecessary because there is this amazing thing Haskell can do natively,
      it's called "lazyness" :)
      
      We simply remove the UNPACK and strictness annotations from the constructor
      field corresponding to the z-encoding, making it lazy, and store the
      (pure) z-encoded string there.
      
      The only complication here is 'hasZEncoding' which allows cheking if a
      z-encoding was computed for a given string. Since this is only used for
      compiler performance statistics though it's not actually necessary to have
      the current per-string granularity.
      
      Instead I add a global IORef counter to the FastStringTable and use
      unsafePerformIO to increment the counter whenever a lazy z-encoding is
      forced.
      4cf91d1a
  5. 24 May, 2019 1 commit
    • Michael Sloan's avatar
      Add PlainPanic for throwing exceptions without depending on pprint · d9dfbde3
      Michael Sloan authored
      This commit splits out a subset of GhcException which do not depend on
      pretty printing (SDoc), as a new datatype called
      PlainGhcException. These exceptions can be caught as GhcException,
      because 'fromException' will convert them.
      
      The motivation for this change is that that the Panic module
      transitively depends on many modules, primarily due to pretty printing
      code.  It's on the order of about 130 modules.  This large set of
      dependencies has a few implications:
      
      1. To avoid cycles / use of boot files, these dependencies cannot
      throw GhcException.
      
      2. There are some utility modules that use UnboxedTuples and also use
      `panic`. This means that when loading GHC into GHCi, about 130
      additional modules would need to be compiled instead of
      interpreted. Splitting the non-pprint exception throwing into a new
      module resolves this issue. See #13101
      d9dfbde3
  6. 31 Jan, 2019 1 commit
  7. 29 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
  8. 22 Nov, 2018 2 commits
    • Zejun Wu's avatar
      Fix deadlock bug when mkFastStringWith is duplicated · f088c2d4
      Zejun Wu authored
      In D5211, we use `withMVar` to guard writes to the same segment, this
      is unsafe to be duplicated. It can lead to deadlock if it is only run
      partially and `putMVar` is not called after `takeMVar`.
      
      Test Plan:
        ./validate
      
      We used to see deadlock when building stackage without this fix, and it
      no longer happens.
      
      Reviewers: simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5349
      f088c2d4
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4881
      13bb4bf4
  9. 28 Oct, 2018 1 commit
    • Zejun Wu's avatar
      Rewrite FastString table in concurrent hashtable · 5126764b
      Zejun Wu authored
      Summary:
      Reimplement global FastString table using a concurrent hashatable with
      fixed size segments and dynamically growing buckets instead of fixed size
      buckets.
      
      This addresses the problem that `mkFastString` was not linear when the
      total number of entries was large.
      
      Test Plan:
      ./validate
      
      ```
      inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null
      GHCi, version 8.7.20181005: http://www.haskell.org/ghc/  :? for help
      Prelude> Leaving GHCi.
      FastString stats:
          segments:          256
          buckets:           16384
          entries:           7117
          largest segment:   64
          smallest segment:  64
          longest bucket:    5
          has z-encoding:    0%
      ```
      
      Also comapre the two implementation using
      
      {P187}
      
      The new implementation is on a par with the old version with different
      conbination of parameters and perform better when the number of
      FastString's are large.
      
      {P188}
      
      Reviewers: simonmar, bgamari, niteria
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #14854
      
      Differential Revision: https://phabricator.haskell.org/D5211
      5126764b
  10. 13 May, 2018 1 commit
    • Sylvain Henry's avatar
      Refactor LitString · 7c665f9c
      Sylvain Henry authored
      Refactor LitString so that the string length is computed at most once
      and then stored.
      
      Also remove strlen and memcmp wrappers (it seems like they were a
      workaround for a very old GCC when using -fvia-C).
      
      Bumps haddock submodule.
      
      Reviewers: bgamari, dfeuer, nickkuk
      
      Reviewed By: bgamari, nickkuk
      
      Subscribers: nickkuk, dfeuer, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4630
      7c665f9c
  11. 09 Nov, 2017 1 commit
  12. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  13. 31 Aug, 2017 1 commit
  14. 18 Apr, 2017 1 commit
  15. 17 Dec, 2016 1 commit
  16. 11 Dec, 2016 1 commit
    • Moritz Angermann's avatar
      Make globals use sharedCAF · c3c70244
      Moritz Angermann authored
      Summary:
      The use of globals is quite painful when multiple rts are loaded, e.g.
      when plugins are loaded, which bring in a second rts. The sharedCAF
      appraoch was employed for the FastStringTable; I've taken the libery
      to extend this to the other globals I could find.
      
      This is a reboot of D2575, that should hopefully not exhibit the same
      windows build issues.
      
      Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd
      
      Reviewed By: Phyx, simonmar, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2773
      c3c70244
  17. 30 Nov, 2016 1 commit
  18. 29 Nov, 2016 1 commit
    • Moritz Angermann's avatar
      Make globals use sharedCAF · 6f7ed1e5
      Moritz Angermann authored
      The use of globals is quite painful when multiple rts are loaded, e.g.
      when plugins are loaded, which bring in a second rts. The sharedCAF
      appraoch was employed for the FastStringTable; I've taken the libery
      to extend this to the other globals I could find.
      
      Reviewers: rwbarton, simonmar, austin, hvr, erikd, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2575
      6f7ed1e5
  19. 22 Jul, 2016 1 commit
    • Simon Marlow's avatar
      Add deepseq dependency and a few NFData instances · c4f3d91b
      Simon Marlow authored
      I needed to rnf a data structure (CompiledByteCode) but we don't have
      any good deepseq infrastructure in the compiler yet.  There are bits and
      pieces, but nothing consistent, so this is a start.
      
      We already had a dependency on deepseq indirectly via other packages
      (e.g. containers).
      
      Includes an update to the haddock submodule, to remove orphan NFData
      instances in there.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, erikd, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2418
      c4f3d91b
  20. 08 Jul, 2016 3 commits
  21. 24 May, 2016 1 commit
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Summary:
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: austin, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2260
      95dfdceb
  22. 04 Mar, 2016 1 commit
  23. 31 Dec, 2015 1 commit
  24. 24 Aug, 2015 1 commit
  25. 21 Aug, 2015 1 commit
    • thomie's avatar
      Refactor: delete most of the module FastTypes · 2f29ebbb
      thomie authored
      This reverses some of the work done in #1405, and goes back to the
      assumption that the bootstrap compiler understands GHC-haskell.
      
      In particular:
        * use MagicHash instead of _ILIT and _CLIT
        * pattern matching on I# if possible, instead of using iUnbox
          unnecessarily
        * use Int#/Char#/Addr# instead of the following type synonyms:
          - type FastInt   = Int#
          - type FastChar  = Char#
          - type FastPtr a = Addr#
        * inline the following functions:
          - iBox           = I#
          - cBox           = C#
          - fastChr        = chr#
          - fastOrd        = ord#
          - eqFastChar     = eqChar#
          - shiftLFastInt  = uncheckedIShiftL#
          - shiftR_FastInt = uncheckedIShiftRL#
          - shiftRLFastInt = uncheckedIShiftRL#
        * delete the following unused functions:
          - minFastInt
          - maxFastInt
          - uncheckedIShiftRA#
          - castFastPtr
          - panicDocFastInt and pprPanicFastInt
        * rename panicFastInt back to panic#
      
      These functions remain, since they actually do something:
        * iUnbox
        * bitAndFastInt
        * bitOrFastInt
      
      Test Plan: validate
      
      Reviewers: austin, bgamari
      
      Subscribers: rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D1141
      
      GHC Trac Issues: #1405
      2f29ebbb
  26. 28 Jan, 2015 1 commit
  27. 03 Dec, 2014 1 commit
  28. 21 Nov, 2014 1 commit
  29. 23 Sep, 2014 1 commit
  30. 16 Sep, 2014 1 commit
    • thomie's avatar
      Return nBytes instead of nextAddr from utf8DecodeChar · caf449e3
      thomie authored
      Summary:
      While researching D176, I came across the following simplification
      opportunity:
      
      Not all functions that call utf8DecodeChar actually need the address
      of the next char. And some need the 'number of bytes' read. So returning
      nBytes instead of nextAddr should save a few addition and subtraction
      operations, and makes the code a bit simpler.
      
      Test Plan: it validates
      
      Reviewers: simonmar, ezyang, austin
      
      Reviewed By: austin
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D179
      caf449e3
  31. 29 Aug, 2014 1 commit
  32. 07 Aug, 2014 1 commit
  33. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  34. 24 Feb, 2014 1 commit
  35. 25 Oct, 2013 1 commit
  36. 18 Sep, 2013 1 commit
    • Jan Stolarek's avatar
      Restore old names of comparison primops · 53948f91
      Jan Stolarek authored
      In 6579a6c7 we removed existing comparison primops and introduced new ones
      returning Int# instead of Bool. This commit (and associated commits in
      array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and
      template-haskell) restores old names of primops. This allows us to keep
      our API cleaner at the price of not having backwards compatibility.
      
      This patch also temporalily disables fix for #8317 (optimization of
      tagToEnum# at Core level). We need to fix #8326 first, otherwise
      our primops code will be very slow.
      53948f91