1. 01 Oct, 2020 1 commit
  2. 09 Sep, 2020 1 commit
  3. 26 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      Refactor UnitId pretty-printing · 0b17fa18
      Sylvain Henry authored
      When we pretty-print a UnitId for the user, we try to map it back to its
      origin package name, version and component to print
      "package-version:component" instead of some hash.
      The UnitId type doesn't carry these information, so we have to look into
      a UnitState to find them. This is why the Outputable instance of
      UnitId used `sdocWithDynFlags` in order to access the `unitState` field
      of DynFlags.
      This is wrong for several reasons:
      1. The DynFlags are accessed when the message is printed, not when it is
         generated. So we could imagine that the unitState may have changed
         in-between. Especially if we want to allow unit unloading.
      2. We want GHC to support several independent sessions at once, hence
         several UnitState. The current approach supposes there is a unique
         UnitState as a UnitId doesn't indicate which UnitState to use.
      See the Note [Pretty-printing UnitId] in GHC.Unit for the new approach
      implemented by this patch.
      One step closer to remove `sdocDynFlags` field from `SDocContext`
      Fix #18124.
      Also fix some Backpack code to use SDoc instead of String.
  4. 13 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      Add HomeUnit type · ffc0d578
      Sylvain Henry authored
      Since Backpack the "home unit" is much more involved than what it was
      before (just an identifier obtained with `-this-unit-id`). Now it is
      used in conjunction with `-component-id` and `-instantiated-with` to
      configure module instantiations and to detect if we are type-checking an
      indefinite unit or compiling a definite one.
      This patch introduces a new HomeUnit datatype which is much easier to
      understand. Moreover to make GHC support several packages in the same
      instances, we will need to handle several HomeUnits so having a
      dedicated (documented) type is helpful.
      Finally in #14335 we will also need to handle the case where we have no
      HomeUnit at all because we are only loading existing interfaces for
      plugins which live in a different space compared to units used to
      produce target code. Several functions will have to be refactored to
      accept "Maybe HomeUnit" parameters instead of implicitly querying the
      HomeUnit fields in DynFlags. Having a dedicated type will make this
      Bump haddock submodule
  5. 12 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: disentangle Outputable · accbc242
      Sylvain Henry authored
      - put panic related functions into GHC.Utils.Panic
      - put trace related functions using DynFlags in GHC.Driver.Ppr
      One step closer making Outputable fully independent of DynFlags.
      Bump haddock submodule
  6. 25 Jul, 2020 1 commit
  7. 27 Jun, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: don't store buildTag · a04020b8
      Sylvain Henry authored
      `DynFlags.buildTag` was a field created from the set of Ways in
      `DynFlags.ways`. It had to be kept in sync with `DynFlags.ways` which
      was fragile. We want to avoid global state like this (#17957).
      Moreover in #14335 we also want to support loading units with different
      ways: target units would still use `DynFlags.ways` but plugins would use
      `GHC.Driver.Ways.hostFullWays`. To avoid having to deal both with build
      tag and with ways, we recompute the buildTag on-the-fly (should be
      pretty cheap) and we remove `DynFlags.buildTag` field.
  8. 13 Jun, 2020 5 commits
    • Sylvain Henry's avatar
      Rename Package into Unit (2) · 653d17bd
      Sylvain Henry authored
      * rename PackageState into UnitState
      * rename findWiredInPackages into findWiredInUnits
      * rename lookupModuleInAll[Packages,Units]
      * etc.
    • Sylvain Henry's avatar
      Rename Package into Unit · ed533ec2
      Sylvain Henry authored
      The terminology changed over time and now package databases contain
      "units" (there can be several units compiled from a single Cabal
      package: one per-component, one for each option set, one per
      instantiation, etc.). We should try to be consistent internally and use
      "units": that's what this renaming does. Maybe one day we'll fix the UI
      too (e.g. replace -package-id with -unit-id, we already have
      -this-unit-id and ghc-pkg has -unit-id...) but it's not done in this
      * rename getPkgFrameworkOpts into getUnitFrameworkOpts
      * rename UnitInfoMap into ClosureUnitInfoMap
      * rename InstalledPackageIndex into UnitInfoMap
      * rename UnusablePackages into UnusableUnits
      * rename PackagePrecedenceIndex into UnitPrecedenceMap
      * rename PackageDatabase into UnitDatabase
      * rename pkgDatabase into unitDatabases
      * rename pkgState into unitState
      * rename initPackages into initUnits
      * rename renamePackage into renameUnitInfo
      * rename UnusablePackageReason into UnusableUnitReason
      * rename getPackage* into getUnit*
      * etc.
    • Sylvain Henry's avatar
      Enhance UnitId use · e7272d53
      Sylvain Henry authored
      * use UnitId instead of String to identify wired-in units
      * use UnitId instead of Unit in the backend (Unit are only use by
        Backpack to produce type-checked interfaces, not real code)
      * rename lookup functions for consistency
      * documentation
    • Sylvain Henry's avatar
      Add allowVirtualUnits field in PackageState · f6be6e43
      Sylvain Henry authored
      Instead of always querying DynFlags to know whether we are allowed to
      use virtual units (i.e. instantiated on-the-fly, cf Note [About units]
      in GHC.Unit), we store it once for all in
      This avoids using DynFlags too much (cf #17957) and is preliminary work
      for #14335.
    • Sylvain Henry's avatar
      Refactor homeUnit · 72d08610
      Sylvain Henry authored
      * rename thisPackage into homeUnit
      * document and refactor several Backpack things
  9. 10 Jun, 2020 1 commit
  10. 05 May, 2020 1 commit
  11. 30 Apr, 2020 3 commits
    • Sylvain Henry's avatar
      Unit: split and rename modules · 8bfb0219
      Sylvain Henry authored
      Introduce GHC.Unit.* hierarchy for everything concerning units, packages
      and modules.
      Update Haddock submodule
    • Sylvain Henry's avatar
      Refactoring unit management code · 10d15f1e
      Sylvain Henry authored
      Over the years the unit management code has been modified a lot to keep
      up with changes in Cabal (e.g. support for several library components in
      the same package), to integrate BackPack, etc. I found it very hard to
      understand as the terminology wasn't consistent, was referring to past
      concepts, etc.
      The terminology is now explained as clearly as I could in the Note
      "About Units" and the code is refactored to reflect it.
      Many names were misleading: UnitId is not an Id but could be a virtual
      unit (an indefinite one instantiated on the fly), IndefUnitId
      constructor may contain a definite instantiated unit, etc.
         * Rename IndefUnitId into InstantiatedUnit
         * Rename IndefModule into InstantiatedModule
         * Rename UnitId type into Unit
         * Rename IndefiniteUnitId constructor into VirtUnit
         * Rename DefiniteUnitId constructor into RealUnit
         * Rename packageConfigId into mkUnit
         * Rename getPackageDetails into unsafeGetUnitInfo
         * Rename InstalledUnitId into UnitId
      Remove references to misleading ComponentId: a ComponentId is just an
      indefinite unit-id to be instantiated.
         * Rename ComponentId into IndefUnitId
         * Rename ComponentDetails into UnitPprInfo
         * Fix display of UnitPprInfo with empty version: this is now used for
           units dynamically generated by BackPack
      Generalize several types (Module, Unit, etc.) so that they can be used
      with different unit identifier types: UnitKey, UnitId, Unit, etc.
         * GenModule: Module, InstantiatedModule and InstalledModule are now
           instances of this type
         * Generalize DefUnitId, IndefUnitId, Unit, InstantiatedUnit,
      Replace BackPack fake "hole" UnitId by a proper HoleUnit constructor.
      Add basic support for UnitKey. They should be used more in the future to
      avoid mixing them up with UnitId as we do now.
      Add many comments.
      Update Haddock submodule
    • Sylvain Henry's avatar
      Refactor UnitInfo · 10a2ba90
      Sylvain Henry authored
      * Rename InstalledPackageInfo into GenericUnitInfo
      The name InstalledPackageInfo is only kept for alleged backward
      compatibility reason in Cabal. ghc-boot has its own stripped down copy
      of this datatype but it doesn't need to keep the name. Internally we
      already use type aliases (UnitInfo in GHC, PackageCacheFormat in
      * Rename UnitInfo fields: add "unit" prefix and fix misleading names
      * Add comments on every UnitInfo field
      * Rename SourcePackageId into PackageId
      "Package" already indicates that it's a "source package". Installed
      package components are called units.
      Update Haddock submodule
  12. 26 Apr, 2020 1 commit
  13. 18 Apr, 2020 1 commit
    • Sylvain Henry's avatar
      Modules (#13009) · 15312bbb
      Sylvain Henry authored
      * SysTools
      * Parser
      * GHC.Builtin
      * GHC.Iface.Recomp
      * Settings
      Update Haddock submodule
      Metric Decrease:
  14. 29 Mar, 2020 2 commits
    • Sylvain Henry's avatar
      Store ComponentId details · e54500c1
      Sylvain Henry authored
      As far as GHC is concerned, installed package components ("units") are
      identified by an opaque ComponentId string provided by Cabal. But we
      don't want to display it to users (as it contains a hash) so GHC queries
      the database to retrieve some infos about the original source package
      (name, version, component name).
      This patch caches these infos in the ComponentId itself so that we don't
      need to provide DynFlags (which contains installed package informations)
      to print a ComponentId.
      In the future we want GHC to support several independent package states
      (e.g. for plugins and for target code), hence we need to avoid
      implicitly querying a single global package state.
    • Sylvain Henry's avatar
      Modules: Types (#13009) · 1941ef4f
      Sylvain Henry authored
      Update Haddock submodule
      Metric Increase:
  15. 22 Feb, 2020 1 commit
  16. 31 Jan, 2020 1 commit
    • Sylvain Henry's avatar
      Refactor package related code · 29c701c1
      Sylvain Henry authored
      The package terminology is a bit of a mess. Cabal packages contain
      components. Instances of these components when built with some
      flags/options/dependencies are called units. Units are registered into
      package databases and their metadata are called PackageConfig.
      GHC only knows about package databases containing units. It is a sad
      mismatch not fixed by this patch (we would have to rename parameters
      such as `package-id <unit-id>` which would affect users).
      This patch however fixes the following internal names:
      - Renames PackageConfig into UnitInfo.
      - Rename systemPackageConfig into globalPackageDatabase[Path]
      - Rename PkgConfXX into PkgDbXX
      - Rename pkgIdMap into unitIdMap
      - Rename ModuleToPkgDbAll into ModuleNameProvidersMap
      - Rename lookupPackage into lookupUnit
      - Add comments on DynFlags package related fields
      It also introduces a new `PackageDatabase` datatype instead of
      explicitly passing the following tuple: `(FilePath,[PackageConfig])`.
      The `pkgDatabase` field in `DynFlags` now contains the unit info for
      each unit of each package database exactly as they have been read from
      disk. Previously the command-line flag `-distrust-all-packages` would
      modify these unit info. Now this flag only affects the "dynamic"
      consolidated package state found in `pkgState` field. It makes sense
      because `initPackages` could be called first with this
      `distrust-all-packages` flag set and then again (using ghc-api) without
      and it should work (package databases are not read again from disk when
      `initPackages` is called the second time).
      Bump haddock submodule
  17. 12 Sep, 2019 1 commit
    • John Ericson's avatar
      Do not throw away backpack instantiations for module lookup cache · a06629b4
      John Ericson authored
      Currently, there is only one home package so this probably doesn't
      matter. But if we support multiple home packages, they could differ only
      in arguments (same indef component being applied).
      It looks like it used to be this way before
      4e8a0607, but that commit doesn't seem
      to comment on this change in the particular. (It's main purpose is
      creating the InstalledUnitId and recategorizing the UnitId expressions
      Trying this as a separate commit for testing purposes. I leave it to
      others to decide whether this is a good change on its own.
  18. 08 Apr, 2019 1 commit
    • Phuong Trinh's avatar
      Fix #16500: look for interface files in -hidir flag in OneShot mode · 2b3f4718
      Phuong Trinh authored
      We are currently ignoring options set in the hiDir field of hsc_dflags
      when looking for interface files while compiling in OneShot mode. This
      is inconsistent with the behaviour of other directory redirecting fields
      (such as objectDir or hieDir). It is also inconsistent with the
      behaviour of compilation in CompManager mode (a.k.a `ghc --make`) which
      looks for interface files in the directory set in hidir flag. This
      changes Finder.hs so that we use the value of hiDir while looking for
      interface in OneShot mode.
  19. 11 Dec, 2018 1 commit
  20. 22 Nov, 2018 2 commits
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
         Fix unused-import stuff in a better way
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      This led to Trac #13064 and #15393
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      The two important changes are
      * Fix the bug in bestImport
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      In unravalling this I also ended up doing a few other things
      * Refactor RnNames.ImportDeclUsage to use...
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      Subscribers: tdammers, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4881
  21. 16 Sep, 2018 1 commit
  22. 17 Jun, 2018 1 commit
    • 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
      <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:
      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
  23. 14 May, 2018 1 commit
  24. 03 May, 2018 1 commit
  25. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      Reviewed By: bgamari
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      Differential Revision: https://phabricator.haskell.org/D3989
  26. 08 Oct, 2016 3 commits
  27. 05 Jun, 2016 1 commit
  28. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      Test Plan: ./validate
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      Subscribers: goldfire, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D1784
  29. 29 Dec, 2015 1 commit
  30. 22 Dec, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement -hide-all-plugin-packages and -plugin-package(-id), fixing #11244 · 1faf1fca
      Edward Z. Yang authored
      The basic idea is that we have a new set of "exposed modules"
      which are /only/ used for plugins, i.e. -fplugin Foo and
      --frontend Foo.  You can interact with this namespace
      using the flags -plugin-package-id and -plugin-package.
      By default, this namespace contains all modules in the
      user namespace (as before), but you can toggle that using
      There is one nasty hack: GhcMake respects -fplugin in
      GHC_OPTIONS to make local plugins work correctly.  It also
      bails out of you have an import of a module which doesn't
      exist locally or in the package database.  The upshot is
      that we need to be sure to check in the plugin modules
      too, so we don't give a spurious failure when a plugin
      is in the plugin namespace but not the main namespace.
      A better way to fix this would be to distinguish between
      plugin and normal dependencies in ModSummary.
      I cheated a little and tweaked a few existing plugins
      tests to exercise the new code paths.
      TODO: Documentation
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Test Plan: validate
      Reviewers: bgamari, austin, simonpj, duncan
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1661
      GHC Trac Issues: #11244