Skip to content
Snippets Groups Projects
  1. May 26, 2023
    • Matthew Pickering's avatar
      error messages: Don't display ghci specific hints for missing packages · 34b44f7d
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      Tickets like #22884 suggest that it is confusing that GHC used on the
      command line can suggest options which only work in GHCi.
      
      This ticket uses the error message infrastructure to override certain
      error messages which displayed GHCi specific information so that this
      information is only showed when using GHCi.
      
      The main annoyance is that we mostly want to display errors in the same
      way as before, but with some additional information. This means that the
      error rendering code has to be exported from the Iface/Errors/Ppr.hs
      module.
      
      I am unsure about whether the approach taken here is the best or most
      maintainable solution.
      
      Fixes #22884
      34b44f7d
  2. May 04, 2023
    • Rodrigo Mesquita's avatar
      Add hashes to unit-ids created by hadrian · db4be339
      Rodrigo Mesquita authored and Marge Bot's avatar Marge Bot committed
      This commit adds support for computing an inputs hash for packages
      compiled by hadrian. The result is that ABI incompatible packages should
      be given different hashes and therefore be distinct in a cabal store.
      
      Hashing is enabled by the `--flag`, and is off by default as the hash
      contains a hash of the source files. We enable it when we produce
      release builds so that the artifacts we distribute have the right unit
      ids.
      db4be339
  3. Apr 18, 2023
    • Matthew Pickering's avatar
      Convert interface file loading errors into proper diagnostics · 5e1d33d7
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      This patch converts all the errors to do with loading interface files
      into proper structured diagnostics.
      
      * DriverMessage: Sometimes in the driver we attempt to load an interface
        file so we embed the IfaceMessage into the DriverMessage.
      * TcRnMessage: Most the time we are loading interface files during
        typechecking, so we embed the IfaceMessage
      
      This patch also removes the TcRnInterfaceLookupError constructor which
      is superceded by the IfaceMessage, which is now structured compared to
      just storing an SDoc before.
      5e1d33d7
  4. Jan 23, 2023
  5. Dec 01, 2022
  6. Oct 26, 2022
  7. Aug 31, 2022
  8. Jun 27, 2022
  9. May 17, 2022
  10. Nov 20, 2021
  11. Oct 14, 2021
  12. Jun 07, 2021
    • Ryan Scott's avatar
      Introduce `hsExprType :: HsExpr GhcTc -> Type` in the new module · 7ea3b7eb
      Ryan Scott authored and Zubin's avatar Zubin committed
      `GHC.Hs.Syn.Type`
      
      The existing `hsPatType`, `hsLPatType` and `hsLitType` functions have also been
      moved to this module
      
      This is a less ambitious take on the same problem that !2182 and !3866
      attempt to solve. Rather than have the `hsExprType` function attempt to
      efficiently compute the `Type` of every subexpression in an `HsExpr`, this
      simply computes the overall `Type` of a single `HsExpr`.
      
      - Explicitly forbids the `SplicePat` `HsIPVar`, `HsBracket`, `HsRnBracketOut`
        and `HsTcBracketOut` constructors during the typechecking phase by using
        `Void` as the TTG extension field
      - Also introduces `dataConCantHappen` as a domain specific alternative to `absurd`
        to handle cases where the TTG extension points forbid a constructor.
      - Turns HIE file generation into a pure function that doesn't need access to the
        `DsM` monad to compute types, but uses `hsExprType` instead.
      - Computes a few more types during HIE file generation
      - Makes GHCi's `:set +c` command also use `hsExprType` instead of going through
        the desugarer to compute types.
      
      Updates haddock submodule
      
      Co-authored-by: default avatarZubin Duggal <zubin.duggal@gmail.com>
  13. May 24, 2020
  14. May 05, 2020
  15. Apr 07, 2020
  16. Mar 29, 2020
  17. Sep 20, 2019
  18. Sep 16, 2018
  19. Jun 20, 2018
  20. Jun 17, 2018
    • sgillespie's avatar
      Improve error message when importing an unusable package · df0f148f
      sgillespie authored
      If a module cannot be found because it is ignored or from an unusable
      package, report this to the user and the reason it is unusable.
      
      Currently, GHC displays the standard "Cannot find module error". For
      example:
      
      ```
      <no location info>: error:
          Could not find module ‘Control.Monad.Random’
          Perhaps you meant
            Control.Monad.Reader (from mtl-2.2.2)
            Control.Monad.Cont (from mtl-2.2.2)
            Control.Monad.Error (from mtl-2.2.2)
      ```
      
      GHC does, however, indicate unusable/ignored packages with the -v flag:
      
      ```
      package MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA is unusable due to
      missing dependencies:
        fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5
      ```
      
      With this change, I took that message and added it to the output of the
      "Cannot find module" message.
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #4806
      
      Differential Revision: https://phabricator.haskell.org/D4783
      df0f148f
  21. May 14, 2018
  22. May 03, 2018
  23. Feb 06, 2018
  24. Feb 02, 2018
  25. Feb 28, 2017
  26. Feb 22, 2017
  27. Oct 08, 2016
  28. Dec 20, 2015
  29. Dec 17, 2015
  30. Nov 29, 2015
  31. Sep 21, 2015
  32. Jul 21, 2015
  33. Jul 13, 2015
  34. Jun 11, 2015
  35. Apr 07, 2015
    • 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
Loading