1. 21 Jul, 2015 2 commits
  2. 20 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Filter orphan rules based on imports, fixes #10294 and #10420. · 0cb1f5cf
      Edward Z. Yang authored
      Summary:
      If we have an orphan rule in our database, don't apply it
      unless the defining module is transitively imported by the
      module we are processing.  We do this by defining a new RuleEnv
      data type which includes both the RuleBase as well as the set
      of visible orphan modules, and threading this through the
      relevant environments (CoreReader, RuleCheckEnv and ScEnv).
      
      This is analogous to the instances fix we applied in #2182
      4c834fdd
      
      , but done for RULES.
      An important knock-on effect is that we can remove some buggy
      code in LoadInterface which tried to avoid loading interfaces
      that were loaded by plugins (which sometimes caused instances
      and rules to NEVER become visible).
      
      One note about tests: I renamed the old plugins07 test to T10420
      and replaced plugins07 with a test to ensure that a plugin
      import did not cause new rules to be loaded in.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D950
      
      GHC Trac Issues: #10420
      0cb1f5cf
  3. 11 Jun, 2015 2 commits
  4. 22 Apr, 2015 1 commit
  5. 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
  6. 02 Apr, 2015 1 commit
  7. 11 Feb, 2015 1 commit
    • Simon Peyton Jones's avatar
      nameIsLocalOrFrom should include interactive modules · 6ff3db92
      Simon Peyton Jones authored
      The provoking cause was Trac #10019, but it revealed that nameIsLocalOrFrom
      should really include all interactive modules (ones from the 'interactive'
      package).  Previously we had some ad-hoc 'isInteractiveModule' tests with
      some (but not all) the calls to nameIsLocalOrFrom.
      
      See the new comments with Name.nameIsLocalOrFrom.
      6ff3db92
  8. 10 Feb, 2015 1 commit
  9. 15 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Make Core Lint check for locally-bound GlobalIds · d59c59f4
      Simon Peyton Jones authored
      There should be no bindings in this module for a GlobalId;
      except after CoreTidy, when top-level bindings are globalised.
      
      To check for this, I had to make the CoreToDo pass part of the
      environment that Core Lint caries.  But CoreToDo is defined in
      CoreMonad, which (before this patch) called CoreLint.
      
      So I had to do quite a bit of refactoring, moving some
      lint-invoking code into CoreLint itself.  Crucially, I also
      more tcLookupImported_maybe, importDecl, and checkwiredInTyCon
      from TcIface (which use CoreLint) to LoadIface (which doesn't).
      This is probably better structure anyway.
      
      So most of this patch is refactoring. The actual check for
      GlobalIds is in CoreLint.lintAndScopeId
      d59c59f4
  10. 03 Dec, 2014 1 commit
  11. 27 Nov, 2014 1 commit
  12. 18 Nov, 2014 1 commit
  13. 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
  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. 05 Aug, 2014 1 commit
    • 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
  16. 21 Jul, 2014 2 commits
    • Edward Z. Yang's avatar
      9960afe4
    • 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
  17. 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!
      b4856f9f
  18. 30 May, 2014 1 commit
  19. 27 May, 2014 1 commit
  20. 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
  21. 03 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Improve error message when using qualified names in GHCi · e60a841b
      Simon Peyton Jones authored
      When you say
        ghci> :i Foo.x
      GHCi tries to find module Foo and get 'x' from it.  But
      if Foo doesn't exist we don't want to say:
        Attempting to use module ‛Foo’ which is not loaded
      
      This is a bit confusing. Rather we just want to say that
      Foo.x is not in scope.
      e60a841b
  22. 02 Nov, 2013 1 commit
  23. 24 Oct, 2013 1 commit
    • Simon Peyton Jones's avatar
      Suppress AMP warnings with -XNoImplicitPrelude (fixed Trac #8320) · c0270922
      Simon Peyton Jones authored
      The AMP warnings caused 'base' to be loaded even when we were
      compiling 'ghc-prim'.  That is bad, bad, bad.  We got a very
      obscure message
         attempting to use module ‛ghc-prim:GHC.Types’
           (libraries/ghc-prim/./GHC/Types.hs) which is not loaded
      
      See Note [Home module load error] in LoadIface
      c0270922
  24. 22 Sep, 2013 1 commit
  25. 17 Mar, 2013 1 commit
  26. 09 Mar, 2013 1 commit
  27. 30 Jan, 2013 1 commit
  28. 11 Dec, 2012 1 commit
  29. 08 Dec, 2012 1 commit
  30. 07 Dec, 2012 1 commit
  31. 05 Dec, 2012 4 commits
  32. 29 Nov, 2012 1 commit
  33. 23 Nov, 2012 2 commits