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. 04 May, 2017 1 commit
  2. 29 Apr, 2017 1 commit
  3. 23 Feb, 2017 1 commit
  4. 03 Feb, 2017 1 commit
    • Sylvain Henry's avatar
      Ditch static flags · bbd3c399
      Sylvain Henry authored
      This patch converts the 4 lasting static flags (read from the command
      line and unsafely stored in immutable global variables) into dynamic
      flags. Most use cases have been converted into reading them from a DynFlags.
      
      In cases for which we don't have easy access to a DynFlags, we read from
      'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
      It's not perfect (not thread-safe) but it is still better as we can
      set/unset these 4 flags before each run when using GHC API.
      
      Updates haddock submodule.
      
      Rebased and finished by: bgamari
      
      Test Plan: validate
      
      Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2839
      
      GHC Trac Issues: #8440
      bbd3c399
  5. 18 Jan, 2017 1 commit
  6. 18 Oct, 2016 1 commit
  7. 14 Oct, 2016 1 commit
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  8. 08 Oct, 2016 2 commits
  9. 21 Aug, 2016 1 commit
  10. 18 Jun, 2016 1 commit
  11. 17 Jun, 2016 1 commit
  12. 11 Feb, 2016 1 commit
  13. 29 Dec, 2015 2 commits
  14. 21 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Rename GHCi's UI modules into GHCi.UI(.*) · 55250a63
      Herbert Valerio Riedel authored
      Further work refactoring and enhancing GHCi will make it desirable to
      split up GHCi's code-base into multiple modules with specific functions,
      and rather than have several top-level 'Ghci*' modules, it's nicer to
      have a common namespace. This commit is provides the basis for that.
      
      Note that the remaining GHCi.* namespace belongs to the new `ghci`
      package.
      
      Differential Revision: https://phabricator.haskell.org/D1593
      55250a63
  15. 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
  16. 12 Dec, 2015 1 commit
    • Edward Z. Yang's avatar
      Frontend plugins. · a3c2a26b
      Edward Z. Yang authored
      
      
      Summary:
      Frontend plugins enable users to write plugins to replace
      GHC major modes.  E.g. instead of saying
      
          ghc --make A B C
      
      a user can now say
      
          ghc --frontend GHC.Frontend.Shake A B C
      
      which might provide an alternative implementation of a multi-module
      build.  For more details, see the manual entry.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, bgamari, austin, simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1598
      
      GHC Trac Issues: #11194
      a3c2a26b
  17. 16 Nov, 2015 1 commit
  18. 27 Oct, 2015 1 commit
    • niteria's avatar
      Make it possible to have different UniqSupply strategies · 158d2a91
      niteria authored
      To get reproducible/deterministic builds, the way that the Uniques are
      assigned shouldn't matter. This allows to test for that.
      
      It add 2 new flags:
      
      * `-dinitial-unique`
      * `-dunique-increment`
      
      And by varying these you can get interesting effects:
      
      * `-dinitial-unique=0 -dunique-increment 1` - current sequential
        UniqSupply
      
      * `-dinitial-unique=16777215 -dunique-increment -1` - UniqSupply that
        generates in decreasing order
      
      * `-dinitial-unique=1 -dunique-increment PRIME` - where PRIME big enough
        to overflow often - nonsequential order
      
      I haven't proven the usefullness of the last one yet and it's the reason
      why we have to mask the bits with `0xFFFFFF` in `genSym`, so I can
      remove it if it becomes contentious.
      
      Test Plan: validate on harbormaster
      
      Reviewers: simonmar, austin, ezyang, bgamari
      
      Reviewed By: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1360
      
      GHC Trac Issues: #4012
      158d2a91
  19. 19 Oct, 2015 1 commit
  20. 15 Oct, 2015 1 commit
  21. 10 Oct, 2015 1 commit
  22. 21 Sep, 2015 2 commits
    • Edward Z. Yang's avatar
      Unify hsig and hs-boot; add preliminary "hs-boot" merging. · 06d46b1e
      Edward Z. Yang authored
      
      
      This patch drops the file level distinction between hs-boot and hsig;
      we figure out which one we are compiling based on whether or not there
      is a corresponding hs file lying around.
      
      To make the "import A" syntax continue to work for bare hs-boot
      files, we also introduce hs-boot merging, which takes an A.hi-boot
      and converts it to an A.hi when there is no A.hs file in scope.
      This will be generalized in Backpack to merge multiple A.hi files together;
      which means we can jettison the "load multiple interface files" functionality.
      
      This works automatically for --make, but for one-shot compilation
      we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
      from a local A.hi-boot file; Backpack will extend this mechanism further.
      
      Has Haddock submodule update to deal with change in msHsFilePath behavior.
      
          - This commit drops support for the hsig extension. Can
            we support it?  It's annoying because the finder code is
            written with the assumption that where there's an hs-boot
            file, there's always an hs file too.  To support hsig, you'd
            have to probe two locations.  Easier to just not support it.
      
          - #10333 affects us, modifying an hs-boot still doesn't trigger
            recomp.
      
          - See compiler/main/Finder.hs: this diff is very skeevy, but
            it seems to work.
      
          - This code cunningly doesn't drop hs-boot files from the
            "drop hs-boot files" module graph, if they don't have a
            corresponding hs file.  I have no idea if this actually is useful.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, spinda
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1098
      06d46b1e
    • Edward Z. Yang's avatar
      3f13c20e
  23. 29 Aug, 2015 1 commit
    • Michael Snoyman's avatar
      Respect GHC_CHARENC environment variable #10762 · 1b56c405
      Michael Snoyman authored
      Only supports UTF-8 as a value right now. I expect some discussion to go
      on around the naming of this variable and whether it's valid to backport
      it to GHC 7.10 (which would be my preference). The motivation here is
      that, when capturing the output of GHC to a file, we often want to
      ensure that the output is UTF-8, regardless of the actual character
      encoding of the terminal/console.
      
      On the other hand, we don't want to necessary change the
      terminal/console encoding. The reason being:
      
      * On Windows, this requires a global-esque change to the console
        codepage, which adversely affects other processes in the same console
      
      * On all OSes, this can break features like smart quote auto-detection.
      
      Test Plan:
      Set LANG to C, GHC_CHARENC to UTF-8, and compile a Haskell source
      file with a non-ASCII warning produced. The output who include the UTF-8
      sequence instead of replacing it with ?.
      
      Reviewers: austin, rwbarton, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: hsyl20, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1167
      
      GHC Trac Issues: #10762
      1b56c405
  24. 18 Aug, 2015 1 commit
    • Michael Snoyman's avatar
      Transliterate unknown characters at output · 22aca536
      Michael Snoyman authored
      This avoids the compiler from crashing when, for example, a warning
      contains a non-Latin identifier and the LANG variable is set to C.
      Fixes #6037.
      
      Test Plan:
      Create a Haskell source file containing an identifier with non-Latin
      characters and no type signature. Compile with `LANG=C ghc -Wall
      foo.hs`, and it should fail. With this patch, it will succeed.
      
      Reviewers: austin, rwbarton, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1153
      
      GHC Trac Issues: #6037, #10762
      22aca536
  25. 21 Jul, 2015 1 commit
  26. 11 Jun, 2015 1 commit
  27. 07 Apr, 2015 1 commit
    • Edward Z. Yang's avatar
      Support for multiple signature files in scope. · a7524eae
      Edward Z. Yang authored
      
      
      Summary:
      A common pattern when programming with signatures is to combine multiple
      signatures together (signature linking).  We achieve this by making it
      not-an-error to have multiple, distinct interface files for the same module
      name, as long as they have the same backing implementation.  When a user
      imports a module name, they get ALL matching signatures dumped into their
      scope.
      
      On the way, I refactored the module finder code, which now distinguishes
      between exact finds (when you had a 'Module') and regular finds (when
      you had a 'ModuleName').  I also refactored the package finder code to
      use a Monoid instance on LookupResult to collect together various results.
      
      ToDo: At the moment, if a signature is declared in the local package,
      it completely overrides any remote signatures.  Eventually, we'll want
      to also pull in the remote signatures (or even override the local signature,
      if the full implementation is available.)  There are bunch of ToDos in the
      code for what to do once this is done.
      
      ToDo: At the moment, whenever a module name lookup occurs in GHCi and we
      would have seen a signature, we instead continue and return the Module
      for the backing implementation.  This is correct for most cases, but there
      might be some situations where we want something a little more fine-grained
      (e.g. :browse should only list identifiers which are available through
      the in-scope signatures, and not ALL of them.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, hvr, austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D790
      
      GHC Trac Issues: #9252
      a7524eae
  28. 01 Apr, 2015 1 commit
    • thomie's avatar
      Change which files --make thinks are 'Haskellish' (#10220) · 7cec6c7b
      thomie authored
      `.hspp` and `.hscpp` are haskell files that have already been preprocessed.
      
      Treat `.hspp` and `.hscpp` as Haskellish sources again, as they were before
      commit a10e1990. This way, ghc --make will load their imports.
      
      Make sure that `.cmm` and `.cmmcpp` are still not treated as Haskellish,
      by moving them out of `haskell_src_suffixes` (but still keeping them in
      haskellish_suffixes, though I'm not sure what the purpose of that group
      is).
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D778
      7cec6c7b
  29. 31 Mar, 2015 1 commit
  30. 28 Mar, 2015 1 commit
  31. 27 Mar, 2015 1 commit
    • thomie's avatar
      Rename driver phases C(obj)cpp to C(obj)cplusplus · abde5da4
      thomie authored
      Before:
      Cpp     = Pre-process C
      Ccpp    = Compile C++
      Cobjcpp = Compile Objective-C++
      CmmCpp  = Pre-process Cmm
      
      Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and
      `Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for
      `pre-processing` throughout the compiler.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D756
      abde5da4
  32. 18 Mar, 2015 1 commit
  33. 16 Mar, 2015 1 commit
    • thomie's avatar
      Dont call unsafeGlobalDynFlags if it is not set · 5166ee94
      thomie authored
      Parsing of static and mode flags happens before any session is started,
      i.e., before the first call to 'GHC.withGhc'. Therefore, to report
      errors for invalid usage of these two types of flags, we can not call
      any function that needs DynFlags, as there are no DynFlags available yet
      (unsafeGlobalDynFlags is not set either). So we always print "on the
      commandline" as the location, which is true except for Api users, which
      is probably ok.
      
      When reporting errors for invalid usage of dynamic flags we /can/ make
      use of DynFlags, and we do so explicitly in
      DynFlags.parseDynamicFlagsFull.
      
      Before, we called unsafeGlobalDynFlags when an invalid (combination of)
      flag(s) was given on the commandline, resulting in panics (#9963). This
      regression was introduced in 1d6124de.
      
      Also rename showSDocSimple to showSDocUnsafe, to hopefully prevent this
      from happening again.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D730
      
      GHC Trac Issues: #9963
      5166ee94
  34. 27 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Embed Git commit id into `ghc --info` output · 73e5e2f8
      Herbert Valerio Riedel authored
      Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
      commit id uniquely identifies the state of the GHC source-tree. So
      having that information embedded into the `ghc` executable provides
      valuable information to track accurately (especially when created by
      buildbots) from which source-tree-state a given `ghc` snapshot
      (distribution) was generated.
      
      So this commit adds a new field `"Project Git commit id"` to the
      `ghc --info` meta-data containing the `./configure`-time Git commit id
      as reported by `git rev-parse HEAD`.
      
      This field can also be queried with `ghc --print-project-git-commit-id`.
      
      For source distributions, the file `GIT_COMMIT_ID` is created (with some
      sanity checking to detect stale commit ids, as that would render this
      information rather useless)
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D528
      73e5e2f8
  35. 21 Nov, 2014 1 commit
    • Lennart Kolmodin's avatar
      ghc: allow --show-options and --interactive together · 624a7c5a
      Lennart Kolmodin authored
      Summary:
      Previously 'ghc --show-options' showed all options that GHC can possibly
      accept. With this patch, it'll only show the options that have effect in
      non-interactive modes.
      This change also adds support for using 'ghc --interactive --show-options'
      which previously was disallowed. This command will show all options that have
      effect in the interactive mode.
      The CmdLineParser is updated to know about the GHC modes, and then each flag
      is annotated with which mode it has effect.
      This fixes #9259.
      
      Test Plan:
      Try out --show-options with --interactive on the command line. With and without
      --interactive should give different results.
      Run the test suite, mode001 has been updated to verify this new flag
      combination.
      
      Reviewers: austin, jstolarek
      
      Reviewed By: austin, jstolarek
      
      Subscribers: jstolarek, thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D337
      
      GHC Trac Issues: #9259
      624a7c5a
  36. 19 Nov, 2014 1 commit
  37. 23 Sep, 2014 1 commit
    • thomie's avatar
      Delete hack when takeDirectory returns "" · 2a743bbd
      thomie authored
      Summary:
      Since commits 8fe1f8 and bb6731 in the filepath packages (ticket #2034, closed
      in 2010), takeDirectory "foo" returns ".", and not "", so this check is no
      longer needed.
      
      Other commits:
      * Remove trailing whitespace
      * Update comments for #2278
      
      Test Plan: harbormaster
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D213
      
      GHC Trac Issues: #2034
      2a743bbd