1. 09 Mar, 2015 1 commit
  2. 10 Feb, 2015 1 commit
  3. 03 Jan, 2015 2 commits
  4. 03 Dec, 2014 1 commit
  5. 19 Nov, 2014 1 commit
  6. 18 Nov, 2014 1 commit
  7. 30 Oct, 2014 1 commit
  8. 27 Oct, 2014 1 commit
  9. 24 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Implementation of hsig (module signatures), per #9252 · aa479953
      Edward Z. Yang authored
      
      
      Summary:
      Module signatures, like hs-boot files, are Haskell modules which omit
      value definitions and contain only signatures.  This patchset implements
      one particular aspect of module signature, namely compiling them against
      a concrete implementation.  It works like this: when we compile an hsig
      file, we must be told (via the -sig-of flag) what module this signature
      is implementing.  The signature is compiled into an interface file which
      reexports precisely the entities mentioned in the signature file.  We also
      verify that the interface is compatible with the implementation.
      
      This feature is useful in a few situations:
      
          1. Like explicit import lists, signatures can be used to reduce
          sensitivity to upstream changes.  However, a signature can be defined
          once and then reused by many modules.
      
          2. Signatures can be used to quickly check if a new upstream version
          is compatible, by typechecking just the signatures and not the actual
          modules.
      
          3. A signature can be used to mediate separate modular development,
          where the signature is used as a placeholder for functionality which
          is loaded in later.  (This is only half useful at the moment, since
          typechecking against signatures without implementations is not implemented
          in this patchset.)
      
      Unlike hs-boot files, hsig files impose no performance overhead.
      
      This patchset punts on the type class instances (and type families) problem:
      instances simply leak from the implementation to the signature.  You can
      explicitly specify what instances you expect to have, and those will be checked,
      but you may get more instances than you asked for.  Our eventual plan is
      to allow hiding instances, but to consider all transitively reachable instances
      when considering overlap and soundness.
      
      ToDo: signature merging: when a module is provided by multiple signatures
      for the same base implementation, we should not consider this ambiguous.
      
      ToDo: at the moment, signatures do not constitute use-sites, so if you
      write a signature for a deprecated function, you won't get a warning
      when you compile the signature.
      
      Future work: The ability to feed in shaping information so that we can take
      advantage of more type equalities than might be immediately evident.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate and new tests
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D130
      
      GHC Trac Issues: #9252
      aa479953
  10. 20 Oct, 2014 1 commit
  11. 19 Oct, 2014 1 commit
  12. 05 Oct, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `MIN_VERSION_GLASGOW_HASKELL()` macro · 3549c952
      Herbert Valerio Riedel authored
      This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
      allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
      would result in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
        #define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623
      
      while GHC 7.10.3 results in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 3
      
      and finally GHC 7.9.20141009 results in
      
        #define __GLASGOW_HASKELL__             709
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009
      
      As it's error-prone to properly express CPP conditionals for testing GHC
      multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
      provided (also via the new CPP include file `ghcversion.h`)
      
      Finally, in order to make it easier to define the new CPP macro
      `MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
      `include/ghcversion.h` is used for the new CPP definitions.
      
      Reviewed By: ekmett, austin, #ghc
      
      Differential Revision: https://phabricator.haskell.org/D66
      3549c952
  13. 02 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename _closure to _static_closure, apply naming consistently. · 35672072
      Edward Z. Yang authored
      Summary:
      In preparation for indirecting all references to closures,
      we rename _closure to _static_closure to ensure any old code
      will get an undefined symbol error.  In order to reference
      a closure foobar_closure (which is now undefined), you should instead
      use STATIC_CLOSURE(foobar).  For convenience, a number of these
      old identifiers are macro'd.
      
      Across C-- and C (Windows and otherwise), there were differing
      conventions on whether or not foobar_closure or &foobar_closure
      was the address of the closure.  Now, all foobar_closure references
      are addresses, and no & is necessary.
      
      CHARLIKE/INTLIKE were not changed, simply alpha-renamed.
      
      Part of remove HEAP_ALLOCED patch set (#8199
      
      )
      
      Depends on D265
      Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@mit.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, austin
      
      Subscribers: simonmar, ezyang, carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D267
      
      GHC Trac Issues: #8199
      35672072
  14. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      
      
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  15. 27 Aug, 2014 1 commit
  16. 10 Aug, 2014 1 commit
  17. 05 Aug, 2014 1 commit
  18. 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
  19. 20 Jul, 2014 1 commit
  20. 27 Jun, 2014 2 commits
  21. 26 Jun, 2014 1 commit
  22. 23 Jun, 2014 2 commits
  23. 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
  24. 03 May, 2014 1 commit
  25. 21 Apr, 2014 1 commit
  26. 11 Apr, 2014 1 commit
  27. 08 Apr, 2014 1 commit
  28. 13 Mar, 2014 1 commit
  29. 19 Feb, 2014 1 commit
  30. 28 Jan, 2014 1 commit
  31. 21 Jan, 2014 1 commit
    • Austin Seipp's avatar
      Fix #8677 (fallout from #8180) · 0a2d323c
      Austin Seipp authored
      
      
      When using TemplateHaskell and -prof, we *do not* want -dynamic-too, because
      we're going to *expect* that you compiled the vanilla/dyn way already,
      and are compiling profiling the second time (i.e. so GHCi can just load
      the normal, non-profiled object files.)
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      0a2d323c
  32. 18 Jan, 2014 1 commit
    • pali.gabor@gmail.com's avatar
      Fix #8451 · 1ad599ea
      pali.gabor@gmail.com authored
      On FreeBSD, /usr/lib has to be added to the library path on linking when
      libthr is needed but -nostdlib is used (which is the case when the -prof
      and -threaded flags are combined).
      1ad599ea
  33. 16 Jan, 2014 1 commit
  34. 14 Jan, 2014 3 commits
  35. 12 Jan, 2014 1 commit
    • Austin Seipp's avatar
      Fix #8180 · ae87e122
      Austin Seipp authored
      
      
      When compiling a set of modules under --make, we need to check if the
      module graph has TemplateHaskell enabled. If it does, then we need to
      switch on -dynamic-too for GHCi, so that the linker can properly find
      the right dynamic object files.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      ae87e122