1. 05 Aug, 2014 2 commits
    • Edward Z. Yang's avatar
      Make PackageState an abstract type. · de3f0644
      Edward Z. Yang authored
      Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D107
      de3f0644
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      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/D80
      66218d15
  2. 02 Aug, 2014 1 commit
  3. 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
  4. 27 Jun, 2014 2 commits
  5. 26 Jun, 2014 1 commit
  6. 08 Jun, 2014 1 commit
  7. 30 May, 2014 1 commit
  8. 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
  9. 03 May, 2014 1 commit
  10. 23 Mar, 2014 1 commit
    • Simon Peyton Jones's avatar
      Simplify handling of the interactive package; fixes Trac #8831 · 28e8d878
      Simon Peyton Jones authored
      This patch is really a fix to the big commint
         73c08ab1
         Re-work the naming story for the GHCi prompt (Trac #8649)
      which introduced the 'interactive' package
      See Note [The interactive package] in HscTypes
      
      The original commit set both
        (a) The tcg_mod field of TcGblEnv to 'interactive:Ghci4' (say)
        (b) The thisPackage field of DynFlags to 'interactive'
      
      But the second step interacts badly with linking.  :loaded modules are
      in the package set by 'thisPackage' (usually 'main'); if you change
      that, then we try to link package 'main', but can't find it, and
      that is what happened in #8831.
      
      The fix was simple: do (a) but not (b).
      
      I changed Note [The interactive package] in HscTypes to describe this.
      28e8d878
  11. 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
          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>
      4f8369bf
  12. 09 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Re-work the naming story for the GHCi prompt (Trac #8649) · 73c08ab1
      Simon Peyton Jones authored
      The basic idea here is simple, and described in Note [The interactive package]
      in HscTypes, which starts thus:
      
          Note [The interactive package]
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Type and class declarations at the command prompt are treated as if
          they were defined in modules
             interactive:Ghci1
             interactive:Ghci2
             ...etc...
          with each bunch of declarations using a new module, all sharing a
          common package 'interactive' (see Module.interactivePackageId, and
          PrelNames.mkInteractiveModule).
      
          This scheme deals well with shadowing.  For example:
      
             ghci> data T = A
             ghci> data T = B
             ghci> :i A
             data Ghci1.T = A  -- Defined at <interactive>:2:10
      
          Here we must display info about constructor A, but its type T has been
          shadowed by the second declaration.  But it has a respectable
          qualified name (Ghci1.T), and its source location says where it was
          defined.
      
          So the main invariant continues to hold, that in any session an original
          name M.T only refers to oe unique thing.  (In a previous iteration both
          the T's above were called :Interactive.T, albeit with different uniques,
          which gave rise to all sorts of trouble.)
      
      This scheme deals nicely with the original problem.  It allows us to
      eliminate a couple of grotseque hacks
        - Note [Outputable Orig RdrName] in HscTypes
        - Note [interactive name cache] in IfaceEnv
      (both these comments have gone, because the hacks they describe are no
      longer necessary). I was also able to simplify Outputable.QueryQualifyName,
      so that it takes a Module/OccName as args rather than a Name.
      
      However, matters are never simple, and this change took me an
      unreasonably long time to get right.  There are some details in
      Note [The interactive package] in HscTypes.
      73c08ab1
  13. 03 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Refactor the way shadowing in handled in GHCi · 5dffb4ac
      Simon Peyton Jones authored
      If you say
        ghci> import Foo( T )
        ghci> data T = MkT
        ghci> data T = XXX
      then the second 'data T' should shadow the first.  But the qualified
      Foo.T should still be available.  We really weren't handling this
      correctly at all, resulting in Trac #8639 and #8628 among others
      
      This patch:
      
      * Add RdrName.extendGlobalRdrEnv, which does shadowing properly
      
      * Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv)
        to use the new function
      
      * Change RnNames.extendGobalRdrEnvRn to use the new function
      
      * Move gresFrom Avails into RdrName
      * Better pprGlobalRdrEnv function in RdrName
      5dffb4ac
  14. 03 Dec, 2013 1 commit
  15. 28 Nov, 2013 1 commit
    • Simon Peyton Jones's avatar
      More faff to get GHCi's top-level environment right · f3a84161
      Simon Peyton Jones authored
      This fixes #8540 (again), and simplifies matters a bit more. In
      particular, I got rid of ic_sys_vars altogether.  Mostly they can just
      go in ic_tythings, apart from dfuns, which are readily gettable from
      the instances anyway.
      
      See documentation in Note [Initialising the type environment for GHCi]
      in TcEnv.
      f3a84161
  16. 21 Nov, 2013 1 commit
  17. 23 Oct, 2013 1 commit
  18. 16 Oct, 2013 2 commits
  19. 22 Sep, 2013 1 commit
  20. 11 Sep, 2013 1 commit
  21. 03 Sep, 2013 1 commit
    • Simon Peyton Jones's avatar
      Improve Linting in GHCi (fixes Trac #8215) · dfa8ef03
      Simon Peyton Jones authored
      The original problem was that we weren't bringing varaibles bound in the
      interactive context into scope before Linting the result of a top-level
      declaration in GHCi.  (We were doing this for expressions.)
      
      Moreover I found that we weren't Linting the result of desugaring
      a GHCi expression, which we really should be doing.
      
      It took me a bit of time to unravel all this, and I did some refactoring
      to make it easier next time.
      
        * CoreMonad contains the Lint wrappers that get the right
          environments into place.  It always had endPass and lintPassResult
          (which Lints bindings), but now it has lintInteractiveExpr.
      
        * Both use a common function CoreMonad.interactiveInScope to find
          those in-scope variables.
      
      Quite a bit of knock-on effects from this, but nothing exciting.
      dfa8ef03
  22. 30 Jul, 2013 1 commit
  23. 28 Jul, 2013 1 commit
  24. 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.
      569b2652
  25. 14 May, 2013 1 commit
    • ian@well-typed.com's avatar
      Fix the GHC package DLL-splitting · 60b86b04
      ian@well-typed.com authored
      There's now an internal -dll-split flag, which we use to tell GHC how
      the GHC package is split into 2 separate DLLs. This is used by
      Packages.isDllName to determine whether a call is within the same
      DLL, or whether it is a call to another DLL.
      60b86b04
  26. 26 Apr, 2013 2 commits
  27. 15 Mar, 2013 1 commit
  28. 09 Mar, 2013 3 commits
  29. 07 Mar, 2013 1 commit
  30. 02 Mar, 2013 1 commit
  31. 22 Jan, 2013 1 commit
  32. 10 Jan, 2013 1 commit
  33. 19 Dec, 2012 1 commit
    • mad.one@gmail.com's avatar
      Rename all of the 'cmmz' flags and make them more consistent. · f6f881f0
      mad.one@gmail.com authored
      There's only a single compiler backend now, so the 'z' suffix means
      nothing. Also, the flags were confusingly named ('cmm-foo' vs
      'foo-cmm',) and counter-intuitively, '-ddump-cmm' did not do at all what
      you expected since the new backend went live.
      
      Basically, all of the -ddump-cmmz-* flags are now -ddump-cmm-*. Some were
      renamed to be more consistent.
      
      This doesn't update the manual; it already mentions '-ddump-cmm' and
      that flag implies all the others anyway, which is probably what you
      want.
      Signed-off-by: mad.one@gmail.com's avatarAustin Seipp <mad.one@gmail.com>
      f6f881f0
  34. 11 Dec, 2012 1 commit