This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 15 May, 2018 1 commit
    • Artem Pelenitsyn's avatar
      Less Tc inside simplCore (Phase 1 for #14391) · bb3fa2d1
      Artem Pelenitsyn authored
      Simplifier depends on typechecker in two points: `thNameToGhcName`
      (`lookupThName_maybe`, in particular)  and `lookupGlobal`. We want to
      cut the ties in two steps.
      
      1. (Presented in this commit), reimplement both functions in a way that
      doesn't use typechecker.
      
      2. (Should follow), do code moving: a) `lookupGlobal` should go in some
      typechecker-free place; b) `thNameToGhcName` should leave simplifier,
      because it is not used there at all (probably, it should be placed
      somewhere where `GhcPlugins` can see it -- this is suggested by Joachim
      on Trac).
      
      Details
      =======
      
      We redesigned lookup interface a bit so that it exposes some
      `IO`-equivalents of `Tc`-features in use.
      
      First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer
      bound to the typechecker monad, but still resides in `TcEnv.hs` — it
      should be moved out of Tc-land at some point (“Phase 2”) in the
      future in order to achieve its part of the #14391's goal.
      
      Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs`
      completely; this already achieves its part of the goal of #14391. Its
      client, though, `thNameToGhcName`, is better to be moved in the future
      also, for it is not used in the `CoreMonad.hs` (or anywhere else)
      anyway. Joachim suggested “any module reexported by GhcPlugins (or
      maybe even that module itself)”.
      
      As a side goal, we removed `initTcForLookup` which was instrumental for
      the past version of `lookupGlobal`. This, in turn, called for pushing
      some more parts of the lookup interface from the `Tc`-monad to `IO`,
      most notably, adding `IO`-version of `lookupOrig` and pushing
      `dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn,
      triggered a slight redesign of name cache updating interface: we now
      have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod`
      and `occ` to force them inside, instead of more error-prone outside
      before. But all these hardly have to do anything with #14391, mere
      refactoring.
      
      Reviewers: simonpj, nomeata, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14391
      
      Differential Revision: https://phabricator.haskell.org/D4503
      bb3fa2d1
  2. 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
  3. 02 Jun, 2017 1 commit
    • Ryan Scott's avatar
      Use lengthIs and friends in more places · a786b136
      Ryan Scott authored
      While investigating #12545, I discovered several places in the code
      that performed length-checks like so:
      
      ```
      length ts == 4
      ```
      
      This is not ideal, since the length of `ts` could be much longer than 4,
      and we'd be doing way more work than necessary! There are already a slew
      of helper functions in `Util` such as `lengthIs` that are designed to do
      this efficiently, so I found every place where they ought to be used and
      did just that. I also defined a couple more utility functions for list
      length that were common patterns (e.g., `ltLength`).
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, goldfire, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: goldfire, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3622
      a786b136
  4. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  5. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  6. 21 Oct, 2015 1 commit
    • Simon Marlow's avatar
      Fix breakage in the GHCi debugger · 7855afba
      Simon Marlow authored
      Summary:
      There was a broken offset calculation that only worked when the
      sections of the binary were in a particular order, and this
      broke (sometimes) after we started mapping the sections separately in
      the linker (see D975).
      
      Test Plan: ghci debugger tests now work with DYNAMIC_GHC_PROGRAMS=NO
      
      Reviewers: austin, hvr, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, thomie, trommler
      
      Differential Revision: https://phabricator.haskell.org/D1346
      
      GHC Trac Issues: #10994
      7855afba
  7. 15 Oct, 2015 1 commit
  8. 05 Nov, 2014 1 commit
  9. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  10. 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
  11. 19 Jun, 2013 1 commit
  12. 23 Jan, 2013 1 commit
  13. 19 Oct, 2012 1 commit
    • Simon Marlow's avatar
      Remove the old codegen · 6fbd46b0
      Simon Marlow authored
      Except for CgUtils.fixStgRegisters that is used in the NCG and LLVM
      backends, and should probably be moved somewhere else.
      6fbd46b0
  14. 18 Sep, 2012 1 commit
  15. 17 Sep, 2012 1 commit
  16. 16 Sep, 2012 1 commit
  17. 24 Jul, 2012 1 commit
  18. 12 Jun, 2012 1 commit
  19. 03 Aug, 2011 1 commit
    • Simon Marlow's avatar
      Fix #5289 (loading libstdc++.so in GHCi), and also fix some other · 9babbc8d
      Simon Marlow authored
      linking scenarios.  We weren't searching for .a archives to satisfy
      -lfoo options on the GHCi command line, for example.
      
      I've tidied up the code in this module so that dealing with -l options
      on the command line is consistent with the handling of extra-libraries
      for packages.
      
      While I was here I moved some stuff out of Linker.hs that didn't seem
      to belong here: dataConInfoPtrToName (now in new module DebuggerUtils)
      and lessUnsafeCoerce (now in DynamicLoading, next to its only use)
      9babbc8d