1. 02 Feb, 2018 1 commit
  2. 28 Feb, 2017 1 commit
  3. 22 Feb, 2017 2 commits
  4. 08 Oct, 2016 2 commits
  5. 20 Dec, 2015 1 commit
  6. 17 Dec, 2015 1 commit
  7. 29 Nov, 2015 1 commit
  8. 21 Sep, 2015 1 commit
  9. 21 Jul, 2015 1 commit
  10. 13 Jul, 2015 1 commit
  11. 11 Jun, 2015 1 commit
  12. 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
  13. 10 Mar, 2015 1 commit
    • Edward Z. Yang's avatar
      Refactor testsuite with normalise_version() · 8cbd7f5d
      Edward Z. Yang authored
      Summary:
      This function generalizes the normaliseBytestringPackage and other similar
      one-off functions into normalise_version() with takes a package name to
      normalize against.  This JUST manages package versions; we also could use
      a normalize for keys.
      
      In the process, I modified all the normalization functions to be accumulative;
      I don't think this makes a difference for current test cases but I think it
      makes things nicer.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Reviewers: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D725
      8cbd7f5d
  14. 22 Dec, 2014 1 commit
  15. 16 Dec, 2014 1 commit
  16. 22 Aug, 2014 2 commits
  17. 05 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Thinning and renaming modules from packages on the command line. · 20787529
      Edward Z. Yang authored
      Summary:
      This patch set adds support for extra syntax on -package and related
      arguments which allow you to thin and rename modules from a package.
      For example, this argument:
      
          -package "base (Data.Bool as Bam, Data.List)"
      
      adds two more modules into scope, Bam and Data.List, without adding
      any of base's other modules to scope.
      
      These flags are additive: so, for example, saying:
      
          -hide-all-packages -package base -package "base (Data.Bool as Bam)"
      
      will provide both the normal bindings for modules in base, as well as
      the module Bam.
      
      There is also a new debug flag -ddump-mod-map which prints the state
      of the module mapping database.  H = hidden, E = exposed (so for
      example EH says the module in question is exported, but in a hidden
      package.)
      
      Module suggestions have been minorly overhauled to work better with reexports:
      if you have -package "base (Data.Bool as Bam)" and mispell Bam, GHC
      will suggest "Did you mean Bam (defined via package flags to be
      base:Data.Bool)"; and generally you will get more accurate information.
      Also, fix a bug where we suggest the -package flag when we really need
      the -package-key flag.
      
      NB: The renaming afforded here does *not* affect what wired in
      symbols GHC generates.  (But it does affect implicit prelude!)
      
      ToDo: add 'hiding' functionality, to make it easier to support the alternative
      prelude use-case.
      
      ToDo: Cabal support
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: new tests and validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D113
      
      GHC Trac Issues: #9375
      20787529