1. 07 Apr, 2020 1 commit
  2. 29 Mar, 2020 2 commits
    • Sylvain Henry's avatar
      Store ComponentId details · e54500c1
      Sylvain Henry authored
      As far as GHC is concerned, installed package components ("units") are
      identified by an opaque ComponentId string provided by Cabal. But we
      don't want to display it to users (as it contains a hash) so GHC queries
      the database to retrieve some infos about the original source package
      (name, version, component name).
      
      This patch caches these infos in the ComponentId itself so that we don't
      need to provide DynFlags (which contains installed package informations)
      to print a ComponentId.
      
      In the future we want GHC to support several independent package states
      (e.g. for plugins and for target code), hence we need to avoid
      implicitly querying a single global package state.
      e54500c1
    • Sylvain Henry's avatar
      Modules: Types (#13009) · 1941ef4f
      Sylvain Henry authored
      Update Haddock submodule
      
      Metric Increase:
         haddock.compiler
      1941ef4f
  3. 17 Mar, 2020 1 commit
  4. 12 Mar, 2020 2 commits
    • Sylvain Henry's avatar
      Use a Set to represent Ways · a6989971
      Sylvain Henry authored
      Should make `member` queries faster and avoid messing up with missing
      `nubSort`.
      
      Metric Increase:
          hie002
      a6989971
    • Sylvain Henry's avatar
      Refactor GHC.Driver.Session (Ways and Flags) · 8e6febce
      Sylvain Henry authored
      * extract flags and ways into their own modules (with some renaming)
      
      * remove one SOURCE import of GHC.Driver.Session from GHC.Driver.Phases
      
      * when GHC uses dynamic linking (WayDyn), `interpWays` was only
        reporting WayDyn even if the host was profiled (WayProf).  Now it
        returns both as expected (might fix #16803).
      
      * `mkBuildTag :: [Way] -> String` wasn't reporting a canonical tag for
        differently ordered lists. Now we sort and nub the list to fix this.
      8e6febce
  5. 29 Feb, 2020 2 commits
    • Sylvain Henry's avatar
      Refactor runtime interpreter code · 18757cab
      Sylvain Henry authored
      In #14335 we want to be able to use both the internal interpreter (for
      the plugins) and the external interpreter (for TH and GHCi) at the same
      time.
      
      This patch performs some preliminary refactoring: the `hsc_interp` field
      of HscEnv replaces `hsc_iserv` and is now used to indicate which
      interpreter (internal, external) to use to execute TH and GHCi.
      
      Opt_ExternalInterpreter flag and iserv options in DynFlags are now
      queried only when we set the session DynFlags. It should help making GHC
      multi-target in the future by selecting an interpreter according to the
      selected target.
      18757cab
    • Vladislav Zavialov's avatar
      Monotonic locations (#17632) · 327b29e1
      Vladislav Zavialov authored
      When GHC is parsing a file generated by a tool, e.g. by the C preprocessor, the
      tool may insert #line pragmas to adjust the locations reported to the user.
      
      As the result, the locations recorded in RealSrcLoc are not monotonic. Elements
      that appear later in the StringBuffer are not guaranteed to have a higher
      line/column number.
      
      In fact, there are no guarantees whatsoever, as #line pragmas can arbitrarily
      modify locations. This lack of guarantees makes ideas such as #17544
      infeasible.
      
      This patch adds an additional bit of information to every SrcLoc:
      
      	newtype BufPos = BufPos { bufPos :: Int }
      
      A BufPos represents the location in the StringBuffer, unaffected by any
      pragmas.
      
      Updates haddock submodule.
      
      Metric Increase:
          haddock.Cabal
          haddock.base
          haddock.compiler
          MultiLayerModules
          Naperian
          parsing001
          T12150
      327b29e1
  6. 26 Feb, 2020 1 commit
  7. 24 Feb, 2020 1 commit
    • Vladislav Zavialov's avatar
      Remove Ord SrcLoc, Ord SrcSpan · 26e8fff3
      Vladislav Zavialov authored
      Before this patch, GHC relied on Ord SrcSpan to identify source elements, by
      using SrcSpan as Map keys:
      
      	blackList :: Map SrcSpan ()      -- compiler/GHC/HsToCore/Coverage.hs
      	instanceMap :: Map SrcSpan Name  -- compiler/GHC/HsToCore/Docs.hs
      
      Firstly, this design is not valid in presence of UnhelpfulSpan, as it
      distinguishes between  UnhelpfulSpan "X"  and  UnhelpfulSpan "Y", but those
      strings are messages for the user, unfit to serve as identifiers for source
      elements.
      
      Secondly, this design made it hard to extend SrcSpan with additional data.
      Recall that the definition of SrcSpan is:
      
      	data SrcSpan =
      	    RealSrcSpan !RealSrcSpan
      	  | UnhelpfulSpan !FastString
      
      Say we want to extend the RealSrcSpan constructor with additional information:
      
      	data SrcSpan =
      	    RealSrcSpan !RealSrcSpan !AdditionalInformation
      	  | UnhelpfulSpan !FastString
      
      	getAdditionalInformation :: SrcSpan -> AdditionalInformation
      	getAdditionalInformation (RealSrcSpan _ a) = a
      
      Now, in order for  Map SrcSpan  to keep working correctly, we must *ignore* additional
      information when comparing SrcSpan values:
      
      	instance Ord SrcSpan where
      	  compare (RealSrcSpan r1 _) (RealSrcSpan r2 _) = compare r1 r2
      	  ...
      
      However, this would violate an important law:
      
      	a == b  therefore  f a == f b
      
      Ignoring  AdditionalInformation  in comparisons would mean that with
      f=getAdditionalInformation, the law above does not hold.
      
      A more robust design is to avoid  Ord SrcSpan  altogether, which is what this patch implements.
      The mappings are changed to use RealSrcSpan instead:
      
      	blackList :: Set RealSrcSpan         -- compiler/GHC/HsToCore/Coverage.hs
      	instanceMap :: Map RealSrcSpan Name  -- compiler/GHC/HsToCore/Docs.hs
      
      All SrcSpan comparisons are now done with explicit comparison strategies:
      
      	SrcLoc.leftmost_smallest
      	SrcLoc.leftmost_largest
      	SrcLoc.rightmost_smallest
      
      These strategies are not subject to the law mentioned above and can easily
      discard both the string stored in  UnhelpfulSpan  and  AdditionalInformation.
      
      Updates haddock submodule.
      26e8fff3
  8. 22 Feb, 2020 1 commit
  9. 14 Feb, 2020 1 commit
  10. 12 Feb, 2020 1 commit
  11. 08 Feb, 2020 3 commits
    • Ben Gamari's avatar
      Fix GhcThreaded setting · bec76733
      Ben Gamari authored
      This adopts a patch from NetBSD's packaging fixing the `GhcThreaded`
      option of the make build system. In addition we introduce a `ghcThreaded`
      option in hadrian's `Flavour` type.
      
      Also fix Hadrian's treatment of the `Use Threaded` entry in `settings`.
      Previously it would incorrectly claim `Use Threaded = True` if we were
      building the `threaded` runtime way. However, this is inconsistent with
      the `make` build system, which defines it to be whether the `ghc`
      executable is linked against the threaded runtime.
      
      Fixes #17692.
      bec76733
    • Ben Gamari's avatar
      compiler: Qualify imports of Data.List · c2e301ae
      Ben Gamari authored
      c2e301ae
    • Richard Eisenberg's avatar
      Introduce IsPass; refactor wrappers. · 7755ffc2
      Richard Eisenberg authored
      There are two main payloads of this patch:
      
      1. This introduces IsPass, which allows e.g. printing
         code to ask what pass it is running in (Renamed vs
         Typechecked) and thus print extension fields. See
         Note [IsPass] in Hs.Extension
      
      2. This moves the HsWrap constructor into an extension
         field, where it rightly belongs. This is done for
         HsExpr and HsCmd, but not for HsPat, which is left
         as an exercise for the reader.
      
      There is also some refactoring around SyntaxExprs, but this
      is really just incidental.
      
      This patch subsumes !1721 (sorry @chreekat).
      
      Along the way, there is a bit of refactoring in GHC.Hs.Extension,
      including the removal of NameOrRdrName in favor of NoGhcTc.
      This meant that we had no real need for GHC.Hs.PlaceHolder, so
      I got rid of it.
      
      Updates haddock submodule.
      
      -------------------------
      Metric Decrease:
          haddock.compiler
      -------------------------
      7755ffc2
  12. 13 Jan, 2020 1 commit
  13. 06 Jan, 2020 1 commit
  14. 30 Nov, 2019 1 commit
  15. 24 Nov, 2019 1 commit
  16. 13 Nov, 2019 1 commit
  17. 26 Oct, 2019 2 commits
    • Ömer Sinan Ağacan's avatar
      Remove redundant -fno-cse options · 4054f0e5
      Ömer Sinan Ağacan authored
      These were probably added with some GLOBAL_VARs, but those GLOBAL_VARs
      are now gone.
      4054f0e5
    • Roland Senn's avatar
      Fix #14690 - :steplocal panics after break-on-error · 1be9c35c
      Roland Senn authored
      `:steplocal` enables only breakpoints in the current top-level binding.
      
      When a normal breakpoint is hit, then the module name and the break id from the `BRK_FUN` byte code
      allow us to access the corresponding entry in a ModBreak table. From this entry we then get the SrcSpan
      (see compiler/main/InteractiveEval.hs:bindLocalsAtBreakpoint).
      With this source-span we can then determine the current top-level binding, needed for the steplocal command.
      
      However, if we break at an exception or at an error, we don't have an BRK_FUN byte-code, so we don't have any source information.
      The function `bindLocalsAtBreakpoint` creates an `UnhelpfulSpan`, which doesn't allow us to determine the current top-level binding.
      To avoid a `panic`, we have to check for `UnhelpfulSpan` in the function `ghc/GHCi/UI.hs:stepLocalCmd`.
      Hence a :steplocal command after a break-on-exception or a break-on-error is not possible.
      1be9c35c
  18. 23 Oct, 2019 1 commit
    • Takenobu Tani's avatar
      Allow command name resolution for GHCi commands with option `!` #17345 · 4798f3b9
      Takenobu Tani authored
      This commit allows command name resolution for GHCi commands
      with option `!` as follows:
      
          ghci> :k! Int
          Int :: *
          = Int
      
      This commit changes implementation as follows:
      
      Before:
        * Prefix match with full string including the option `!` (e.g. `k!`)
      
      After (this patch):
        * Prefix match without option suffix `!` (e.g. `k`)
        * in addition, suffix match with option `!`
      
      See also #8305 and #8113
      4798f3b9
  19. 16 Oct, 2019 1 commit
  20. 13 Oct, 2019 1 commit
  21. 07 Oct, 2019 1 commit
    • Ben Gamari's avatar
      Refactor, document, and optimize LLVM configuration loading · b2577081
      Ben Gamari authored
      As described in the new Note [LLVM Configuration] in SysTools, we now
      load llvm-targets and llvm-passes lazily to avoid the overhead of doing
      so when -fllvm isn't used (also known as "the common case").
      
      Noticed in #17003.
      
      Metric Decrease:
          T12234
          T12150
      b2577081
  22. 05 Oct, 2019 2 commits
    • John Ericson's avatar
      Always enable the external interpreter · 0dded5ec
      John Ericson authored
      You can always just not use or even build `iserv`. I don't think the
      maintenance cost of the CPP is worth...I can't even tell what the
      benefit is.
      0dded5ec
    • John Ericson's avatar
      Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.h · 05419e55
      John Ericson authored
      The generated headers are now generated per stage, which means we can
      skip hacks like `ghc_boot_platform.h` and just have that be the stage 0
      header as proper. In general, stages are to be embraced: freely generate
      everything in each stage but then just build what you depend on, and
      everything is symmetrical and efficient. Trying to avoid stages because
      bootstrapping is a mind bender just creates tons of bespoke
      mini-mind-benders that add up to something far crazier.
      
      Hadrian was pretty close to this "stage-major" approach already, and so
      was fairly easy to fix. Make needed more work, however: it did know
      about stages so at least there was a scaffold, but few packages except
      for the compiler cared, and the compiler used its own counting system.
      That said, make and Hadrian now work more similarly, which is good for
      the transition to Hadrian. The merits of embracing stage aside, the
      change may be worthy for easing that transition alone.
      05419e55
  23. 01 Oct, 2019 2 commits
    • Takenobu Tani's avatar
      Add help message for GHCi :instances command · 97811ef5
      Takenobu Tani authored
      This commit updates GHCi's help message for GHC 8.10.
      97811ef5
    • Ö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
  24. 20 Sep, 2019 1 commit
  25. 09 Sep, 2019 1 commit
    • 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
  26. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  27. 02 Jul, 2019 1 commit
  28. 22 Jun, 2019 1 commit
    • Ben Gamari's avatar
      ghci: Don't rely on resolution of System.IO to base module · 655c6e26
      Ben Gamari authored
      Previously we would hackily evaluate a textual code snippet to compute
      actions to disable I/O buffering and flush the stdout/stderr handles.
      This broke in a number of ways (#15336, #16563).
      
      Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing
      the needed actions. We can then easily refer to these via `Orig` names.
      655c6e26
  29. 20 Jun, 2019 2 commits
    • John Ericson's avatar
      Move 'Platform' to ghc-boot · bff2f24b
      John Ericson authored
      ghc-pkg needs to be aware of platforms so it can figure out which
      subdire within the user package db to use. This is admittedly
      roundabout, but maybe Cabal could use the same notion of a platform as
      GHC to good affect too.
      bff2f24b
    • Roland Senn's avatar
      Fix #1620: ModBreaks.modBreaks_array not initialised · 39c758e1
      Roland Senn authored
      After a :cd command and after setting some package flags,
      GHCi unloads all loaded modules by resetting the list of targets.
      
      This patch deletes eventually defined debugger breakpoints, before GHCi resets the target list.
      
      The common code is factored out into the new function clearAllTargets.
      39c758e1
  30. 12 Jun, 2019 1 commit
  31. 11 Jun, 2019 1 commit
    • Alp Mestanogullari's avatar
      Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETER · 39f50bff
      Alp Mestanogullari authored
      As discussed in #16331, the GHCI macro, defined through 'ghci' flags
      in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
      whether GHC is built with support for an internal interpreter, that runs in
      the same process. It is however overloaded in a few places to mean
      "there is an interpreter available", regardless of whether it's an internal
      or external interpreter.
      
      For the sake of clarity and with the hope of more easily being able to
      build stage 1 GHCs with external interpreter support, this patch splits
      the previous GHCI macro into 3 different ones:
      
      - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
      - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
      - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
      39f50bff