1. 26 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Module reexports, fixing #8407. · 7f5c1086
      Edward Z. Yang authored
      The general approach is to add a new field to the package database,
      reexported-modules, which considered by the module finder as possible
      module declarations.  Unlike declaring stub module files, multiple
      reexports of the same physical package at the same name do not
      result in an ambiguous import.
      Has submodule updates for Cabal and haddock.
      NB: When a reexport renames a module, that renaming is *not* accessible
      from inside the package.  This is not so much a deliberate design choice
      as for implementation expediency (reexport resolution happens only when
      a package is in the package database.)
      TODO: Error handling when there are duplicate reexports/etc is not very
      well tested.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
  2. 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
      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
  3. 20 Jul, 2014 1 commit
    • Mathieu Boespflug's avatar
      Make GHCi permissions checks ignore root user. · fb936e0d
      Mathieu Boespflug authored
      As a security precaution, GHCi helpfully refuses to run a .ghci file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, then the user would be having a bad day anyways.
      This means that .ghci files installed in a global location, say under /usr/local/, can now be read.
      Fixes #9324
      Test Plan:
      $ sudo touch .ghci
      $ ghci
      Notice that the warning about the file being owned by someone else is now gone.
      Reviewers: austin
      Reviewed By: austin
      Subscribers: phaskell, simonmar, carter, nomeata, relrod
      Projects: #ghc
      Differential Revision: https://phabricator.haskell.org/D75
  4. 13 Jul, 2014 1 commit
  5. 07 Jul, 2014 1 commit
  6. 22 Jun, 2014 1 commit
    • Edward Z. Yang's avatar
      Simplify package dump for -v4 · b6352c99
      Edward Z. Yang authored
      Previously, on -v4  and greater, we dumped out the entire package
      database, including lots of metadata that GHC doesn't really care about,
      and is guaranteed to correspond to the equivalent in the local/global
      package databases on disk.  So, to make this output more useful, on -v4
      we instead just print package IDs, and the exposed and trusted flags
      (E and T, which can be tweaked at runtime).
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Test Plan: successful validate
      Reviewers: simonpj
      Subscribers: simonmar, relrod
      Differential Revision: https://phabricator.haskell.org/D24
  7. 13 Jun, 2014 1 commit
  8. 03 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Do pretty-printing of TyThings via IfaceDecl (Trac #7730) · b4856f9f
      Simon Peyton Jones authored
      All the initial work on this was done fy 'archblob' (fcsernik@gmail.com);
      thank you!
      I reviewed the patch, started some tidying, up and then ended up in a huge
      swamp of changes, not all of which I can remember now.  But:
      * To suppress kind arguments when we have -fno-print-explicit-kinds,
          - IfaceTyConApp argument types are in a tagged list IfaceTcArgs
      * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType.
      * When printing data/type family instances for the user, I've made them
        print out an informative RHS, which is a new feature. Thus
              ghci> info T
              data family T a
              data instance T Int = T1 Int Int
              data instance T Bool = T2
      * In implementation terms, pprIfaceDecl has just one "context" argument,
        of type IfaceSyn.ShowSub, which says
             - How to print the binders of the decl
               see note [Printing IfaceDecl binders] in IfaceSyn
             - Which sub-comoponents (eg constructors) to print
      * Moved FastStringEnv from RnEnv to OccName
      It all took a ridiculously long time to do.  But it's done!
  9. 15 May, 2014 1 commit
  10. 14 May, 2014 2 commits
  11. 22 Apr, 2014 1 commit
  12. 08 Apr, 2014 1 commit
  13. 27 Mar, 2014 1 commit
    • Simon Marlow's avatar
      Don't perform permission checks for scripts named with -ghci-script (#6017) · a6f2c852
      Simon Marlow authored
      The user explicitly requested this script on the command-line, so it's
      unnecessary to require that the script is also owned by the user.
      Also, it is currently impossible to make a GHCi wrapper that invokes a
      custom script without first making a copy of the script to circumvent
      the permissions check, which seems wrong.
  14. 05 Mar, 2014 1 commit
  15. 20 Feb, 2014 1 commit
  16. 18 Feb, 2014 2 commits
  17. 17 Feb, 2014 2 commits
    • Austin Seipp's avatar
      Add comments explaining #8754 · b626c3d4
      Austin Seipp authored
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
    • Austin Seipp's avatar
      Fix #8754 in a round-about way. · 5023c917
      Austin Seipp authored
      For some reason on OS X, it seems like -Bsymbolic (which we use for
      hooks into the RTS) isn't working, which results in #8754, where stats
      don't work because defaultHooks doesn't initialize the stats flag. This
      seems to work on Linux static/dynamically, but only on OS X statically.
      After talking with Simon, really, the entire hooks thing is a bit
      fragile. For now, we just work around it (since GHCi is dynamically
      linked) by calling into the defaultHooks ourselves when GHC starts.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
  18. 20 Jan, 2014 1 commit
    • cactus's avatar
      Implement pattern synonyms · 4f8369bf
      cactus authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      The rundown is this:
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
        * Unidirectional patterns are declared like thus:
              pattern P x <- x:_
          The synonym 'P' may only occur in a pattern context:
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
        * Bidirectional patterns are declared like thus:
              pattern P x y = [x, y]
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
              bar :: Int -> [Int]
              bar x = P x 10
        * Patterns can't yet have their own type signatures; signatures are inferred.
        * Pattern synonyms may not be recursive, c.f. type synonyms.
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
              module Foo (pattern Bar) where ...
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
              pattern P x y <- [x, y]
              f (P True True) = True
              f _             = False
              g [True, True] = True
              g _            = False
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      For more information, see the wiki:
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/ImplementationReviewed-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
  19. 09 Jan, 2014 1 commit
  20. 03 Jan, 2014 1 commit
  21. 02 Jan, 2014 1 commit
  22. 05 Dec, 2013 2 commits
  23. 04 Nov, 2013 1 commit
  24. 11 Oct, 2013 1 commit
  25. 09 Oct, 2013 1 commit
  26. 02 Oct, 2013 1 commit
  27. 01 Oct, 2013 3 commits
  28. 22 Sep, 2013 1 commit
  29. 11 Sep, 2013 2 commits
  30. 29 Aug, 2013 1 commit
  31. 27 Aug, 2013 3 commits