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. 13 Jun, 2014 1 commit
  7. 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!
  8. 15 May, 2014 1 commit
  9. 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.
  10. 09 Jan, 2014 1 commit
  11. 03 Jan, 2014 1 commit
  12. 02 Jan, 2014 1 commit
  13. 05 Dec, 2013 2 commits
  14. 04 Nov, 2013 1 commit
  15. 09 Oct, 2013 1 commit
  16. 02 Oct, 2013 1 commit
  17. 01 Oct, 2013 2 commits
    • Simon Peyton Jones's avatar
      Wibble (change of flag name) · ff07927e
      Simon Peyton Jones authored
    • unknown's avatar
      Improve pretty-printing of types · 66c5ddba
      unknown authored
      * The main change is to suppress printing (in types) of
           kind for-alls
           kind applications
        The new flag -fprint-explicit-kinds prints them as before
        (by analogy with the existing -fprint-explicit-foralls)
      * I also took advantage of the fact that SDoc now has access
        to DynFlags, to tidy up the way in which explicit for-alls
        are printed.  Instead of passing a boolean flag around, we
        now simply consult the DynFlags.  Much neater.
      I still need to add documentation for the flag
  18. 22 Sep, 2013 1 commit
  19. 11 Sep, 2013 1 commit
    • Herbert Valerio Riedel's avatar
      GHCi: Fix multi-line input line/column-number refs · 43111a0b
      Herbert Valerio Riedel authored
      This commit addresses #8051 by fixing
       - Incorrect column indices reported in error messages for
         single-line and multi-line input,
       - incorrect line numbers reported in error messages for
         expressions entered in multi-line input, and
       - inhibiting the confusing interaction between `:{` and `:set +m`
         causing the triggering of implicit multi-line continuation
         mode right after `:}` terminates the multi-line entry block.
  20. 29 Aug, 2013 1 commit
  21. 27 Aug, 2013 3 commits
  22. 24 Aug, 2013 1 commit
  23. 10 Aug, 2013 1 commit
  24. 21 Jul, 2013 3 commits
  25. 07 Jul, 2013 3 commits
  26. 21 Jun, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Revise implementation of overlapping type family instances. · 569b2652
      eir@cis.upenn.edu authored
      This commit changes the syntax and story around overlapping type
      family instances. Before, we had "unbranched" instances and
      "branched" instances. Now, we have closed type families and
      open ones.
      The behavior of open families is completely unchanged. In particular,
      coincident overlap of open type family instances still works, despite
      emails to the contrary.
      A closed type family is declared like this:
      > type family F a where
      >   F Int = Bool
      >   F a   = Char
      The equations are tried in order, from top to bottom, subject to
      certain constraints, as described in the user manual. It is not
      allowed to declare an instance of a closed family.
  27. 19 Jun, 2013 1 commit
  28. 15 Jun, 2013 1 commit
  29. 04 Jun, 2013 4 commits