1. 13 Jun, 2020 6 commits
  2. 21 May, 2020 1 commit
  3. 30 Apr, 2020 5 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
      8bfb0219
    • 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,
           PackageDatabase
      
      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
      10d15f1e
    • Sylvain Henry's avatar
      Factorize mungePackagePaths code · ea717aa4
      Sylvain Henry authored
      This patch factorizes the duplicated code used in ghc-pkg and in GHC to
      munge package paths/urls.
      
      It also fixes haddock-html munging in GHC (allowed to be either a file
      or a url) to mimic ghc-pkg behavior.
      ea717aa4
    • Sylvain Henry's avatar
      Refactor UnitInfo load/store from databases · 9e2c8e0e
      Sylvain Henry authored
      Converting between UnitInfo stored in package databases and UnitInfo as
      they are used in ghc-pkg and ghc was done in a very convoluted way (via
      BinaryStringRep and DbUnitModuleRep type classes using fun deps, etc.).
      It was difficult to understand and even more to modify (I wanted to
      try to use a GADT for UnitId but fun deps got in the way).
      
      The new code uses much more straightforward functions to convert between
      the different representations. Much simpler.
      9e2c8e0e
    • 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
      ghc-pkg).
      
      * 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
      10a2ba90
  4. 26 Apr, 2020 1 commit
  5. 21 Apr, 2020 1 commit
    • Sylvain Henry's avatar
      CmmToAsm DynFlags refactoring (#17957) · 747093b7
      Sylvain Henry authored
      * Remove `DynFlags` parameter from `isDynLinkName`: `isDynLinkName` used
        to test the global `ExternalDynamicRefs` flag. Now we test it outside of
        `isDynLinkName`
      
      * Add new fields into `NCGConfig`: current unit id, sse/bmi versions,
        externalDynamicRefs, etc.
      
      * Replace many uses of `DynFlags` by `NCGConfig`
      
      * Moved `BMI/SSE` datatypes into `GHC.Platform`
      747093b7
  6. 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:
          Naperian
          parsing001
      15312bbb
  7. 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.
      e54500c1
    • Sylvain Henry's avatar
      Modules: Types (#13009) · 1941ef4f
      Sylvain Henry authored
      Update Haddock submodule
      
      Metric Increase:
         haddock.compiler
      1941ef4f
  8. 13 Mar, 2020 1 commit
    • Sylvain Henry's avatar
      Rename isDllName · 44fad4a9
      Sylvain Henry authored
      I wanted to fix the dangling comment in `isDllName` ("This is the cause
      of #", #8696 is already mentioned earlier). I took the opportunity to
      change the function name to better reflect what it does.
      44fad4a9
  9. 12 Mar, 2020 2 commits
    • Sylvain Henry's avatar
      Use a Set to represent Ways · a6989971
      Sylvain Henry authored
      Should make `member` queries faster and avoid messing up with missing
      `nubSort`.
      
      Metric Increase:
          hie002
      a6989971
    • Sylvain Henry's avatar
      Refactor GHC.Driver.Session (Ways and Flags) · 8e6febce
      Sylvain Henry authored
      * extract flags and ways into their own modules (with some renaming)
      
      * remove one SOURCE import of GHC.Driver.Session from GHC.Driver.Phases
      
      * when GHC uses dynamic linking (WayDyn), `interpWays` was only
        reporting WayDyn even if the host was profiled (WayProf).  Now it
        returns both as expected (might fix #16803).
      
      * `mkBuildTag :: [Way] -> String` wasn't reporting a canonical tag for
        differently ordered lists. Now we sort and nub the list to fix this.
      8e6febce
  10. 22 Feb, 2020 1 commit
  11. 31 Jan, 2020 2 commits
    • 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
      29c701c1
    • Sylvain Henry's avatar
      Call `interpretPackageEnv` from `setSessionDynFlags` · bf38a20e
      Sylvain Henry authored
      interpretPackageEnv modifies the flags by reading the dreaded package
      environments. It is much less surprising to call it from
      `setSessionDynFlags` instead of reading package environments as a
      side-effect of `initPackages`.
      bf38a20e
  12. 13 Jan, 2020 1 commit
  13. 04 Jan, 2020 1 commit
  14. 18 Dec, 2019 1 commit
    • Sylvain Henry's avatar
      Add GHC-API logging hooks · 58655b9d
      Sylvain Henry authored
      * Add 'dumpAction' hook to DynFlags.
      
      It allows GHC API users to catch dumped intermediate codes and
      information. The format of the dump (Core, Stg, raw text, etc.) is now
      reported allowing easier automatic handling.
      
      * Add 'traceAction' hook to DynFlags.
      
      Some dumps go through the trace mechanism (for instance unfoldings that
      have been considered for inlining). This is problematic because:
      1) dumps aren't written into files even with -ddump-to-file on
      2) dumps are written on stdout even with GHC API
      3) in this specific case, dumping depends on unsafe globally stored
      DynFlags which is bad for GHC API users
      
      We introduce 'traceAction' hook which allows GHC API to catch those
      traces and to avoid using globally stored DynFlags.
      
      * Avoid dumping empty logs via dumpAction/traceAction (but still write
      empty files to keep the existing behavior)
      58655b9d
  15. 28 Nov, 2019 1 commit
  16. 23 Nov, 2019 1 commit
  17. 19 Nov, 2019 1 commit
  18. 23 Oct, 2019 1 commit
    • Andreas Klebinger's avatar
      Make dynflag argument for withTiming pure. · 6beea836
      Andreas Klebinger authored
      19 times out of 20 we already have dynflags in scope.
      
      We could just always use `return dflags`. But this is in fact not free.
      When looking at some STG code I noticed that we always allocate a
      closure for this expression in the heap. Clearly a waste in these cases.
      
      For the other cases we can either just modify the callsite to
      get dynflags or use the _D variants of withTiming I added which
      will use getDynFlags under the hood.
      6beea836
  19. 03 Aug, 2019 1 commit
  20. 19 Jul, 2019 1 commit
  21. 20 Jun, 2019 1 commit
    • John Ericson's avatar
      Move 'Platform' to ghc-boot · bff2f24b
      John Ericson authored
      ghc-pkg needs to be aware of platforms so it can figure out which
      subdire within the user package db to use. This is admittedly
      roundabout, but maybe Cabal could use the same notion of a platform as
      GHC to good affect too.
      bff2f24b
  22. 09 Jun, 2019 1 commit
    • KevinBuhr's avatar
      Handle trailing path separator in package DB names (#16360) · 9d238791
      KevinBuhr authored
      Package DB directories with trailing separator (provided via
      GHC_PACKAGE_PATH or via -package-db) resulted in incorrect calculation of
      ${pkgroot} substitution variable.  Keep the trailing separator while
      resolving as directory or file, but remove it before dropping the last
      path component with takeDirectory.
      
      Closes #16360.
      9d238791
  23. 08 Jun, 2019 1 commit
  24. 29 Mar, 2019 1 commit
    • Michael Peyton Jones's avatar
      Visibility: handle multiple units with the same name · 8a20bfc2
      Michael Peyton Jones authored
      Fixes #16228. The included test case is adapted from the reproduction in
      the issue, and fails without this patch.
      
      ------
      
      We compute an initial visilibity mapping for units based on what is
      present in the package databases. To seed this, we compute a set of all
      the package configs to add visibilities for.
      
      However, this set was keyed off the unit's *package name*. This is
      correct, since we compare packages across databases by version. However,
      we would only ever consider a single, most-preferable unit from the
      database in which it was found.
      
      The effect of this was that only one of the libraries in a Cabal package
      would be added to this initial set. This would cause attempts to use
      modules from the omitted libraries to fail, claiming that the package
      was hidden (even though `ghc-pkg` would correctly show it as visible).
      
      A solution is to do the selection of the most preferable packages
      separately, and then be sure to consider exposing all units in the
      same package in the same package db. We can do this by picking a
      most-preferable unit for each package name, and then considering
      exposing all units that are equi-preferable with that unit.
      
      ------
      
      Why wasn't this bug apparent to all people trying to use sub-libraries
      in Cabal? The answer is that Cabal explicitly passes `-package` and
      `-package-id` flags for all the packages it wants to use, rather than
      relying on the state of the package database. So this bug only really
      affects people who are trying to use package databases produced by Cabal
      outside of Cabal itself.
      
      One particular example of this is the way that the
      Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these
      are equipped with a package database containing all the needed
      package dependencies, and the user is not expected to pass
      `-package` flags explicitly.
      8a20bfc2
  25. 15 Mar, 2019 1 commit
  26. 01 Feb, 2019 1 commit
    • Edward Z. Yang's avatar
      Fix #16219: TemplateHaskell causes indefinite package build error · d6d735c1
      Edward Z. Yang authored
      It should work to write an indefinite package using TemplateHaskell,
      so long as all of the actual TH code lives outside of the package.
      However, cleverness we had to build TH code even when building
      with -fno-code meant that we attempted to build object code for
      modules in an indefinite package, even when the signatures were
      not instantiated.  This patch disables said logic in the event
      that an indefinite package is being typechecked.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@fb.com>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #16219
      
      Differential Revision: https://phabricator.haskell.org/D5475
      d6d735c1
  27. 29 Nov, 2018 1 commit
    • Chaitanya Koparkar's avatar
      Fix #15953 by consistently using dumpIfSet_dyn to print debug output · dcf1f926
      Chaitanya Koparkar authored
      Summary:
      In some modules we directly dump the debugging output to STDOUT
      via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file`
      is enabled, that output should be written to a file. Easily fixed.
      
      Certain tests (T3017, Roles3, T12763 etc.) expect part of the
      output generated by `-ddump-types` to be in 'PprUser' style. However,
      generally we want all other debugging output to use 'PprDump'
      style. `traceTcRn` and `traceTcRnForUser` help us accomplish this.
      
      This patch also documents some missing flags in the users guide.
      
      Reviewers: RyanGlScott, bgamari, hvr
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15953
      
      Differential Revision: https://phabricator.haskell.org/D5382
      dcf1f926
  28. 22 Nov, 2018 1 commit
    • 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 a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      
      * Delete dead code RdrName.greUsedRdrName
      
      Bumps a few submodules.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5312
      6353efc7