1. 19 Jun, 2020 1 commit
  2. 17 Jun, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored
      This is the first step towards implementation of the linear types proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/111).
      
      It features
      
      * A language extension -XLinearTypes
      * Syntax for linear functions in the surface language
      * Linearity checking in Core Lint, enabled with -dlinear-core-lint
      * Core-to-core passes are mostly compatible with linearity
      * Fields in a data type can be linear or unrestricted; linear fields
        have multiplicity-polymorphic constructors.
        If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
      
      The following items are not yet supported:
      
      * a # m -> b syntax (only prefix FUN is supported for now)
      * Full multiplicity inference (multiplicities are really only checked)
      * Decent linearity error messages
      * Linear let, where, and case expressions in the surface language
        (each of these currently introduce the unrestricted variant)
      * Multiplicity-parametric fields
      * Syntax for annotating lambda-bound or let-bound with a multiplicity
      * Syntax for non-linear/multiple-field-multiplicity records
      * Linear projections for records with a single linear field
      * Linear pattern synonyms
      * Multiplicity coercions (test LinearPolyType)
      
      A high-level description can be found at
      https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Implementation
      Following the link above you will find a description of the changes made to Core.
      This commit has been authored by
      
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Matthew Pickering
      * Arnaud Spiwack
      
      With contributions from:
      
      * Mark Barbone
      * Alexander Vershilov
      
      Updates haddock submodule.
      40fa237e
  3. 13 Jun, 2020 4 commits
    • Sylvain Henry's avatar
      Don't return preload units when we set DyNFlags · bfd0a78c
      Sylvain Henry authored
      Preload units can be retrieved in UnitState when needed (i.e. in GHCi)
      bfd0a78c
    • Sylvain Henry's avatar
      DynFlags: add UnitConfig datatype · fca2d25f
      Sylvain Henry authored
      Avoid directly querying flags from DynFlags to build the UnitState.
      Instead go via UnitConfig so that we could reuse this to make another
      UnitState for plugins.
      fca2d25f
    • 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
      patch.
      
      * 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.
      ed533ec2
    • Sylvain Henry's avatar
      Refactor homeUnit · 72d08610
      Sylvain Henry authored
      * rename thisPackage into homeUnit
      * document and refactor several Backpack things
      72d08610
  4. 04 Jun, 2020 1 commit
    • John Ericson's avatar
      Clean up boot vs non-boot disambiguating types · 32a4ae90
      John Ericson authored
      We often have (ModuleName, Bool) or (Module, Bool) pairs for "extended"
      module names (without or with a unit id) disambiguating boot and normal
      modules. We think this is important enough across the compiler that it
      deserves a new nominal product type. We do this with synnoyms and a
      functor named with a `Gen` prefix, matching other newly created
      definitions.
      
      It was also requested that we keep custom `IsBoot` / `NotBoot` sum type.
      So we have it too. This means changing many the many bools to use that
      instead.
      
      Updates `haddock` submodule.
      32a4ae90
  5. 01 Jun, 2020 2 commits
  6. 15 May, 2020 1 commit
    • Sebastian Graf's avatar
      DmdAnal: Improve handling of precise exceptions · 9bd20e83
      Sebastian Graf authored
      This patch does two things: Fix possible unsoundness in what was called
      the "IO hack" and implement part 2.1 of the "fixing precise exceptions"
      plan in
      https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions,
      which, in combination with !2956, supersedes !3014 and !2525.
      
      **IO hack**
      
      The "IO hack" (which is a fallback to preserve precise exceptions
      semantics and thus soundness, rather than some smart thing that
      increases precision) is called `exprMayThrowPreciseException` now.
      I came up with two testcases exemplifying possible unsoundness (if
      twisted enough) in the old approach:
      
      - `T13380d`: Demonstrating unsoundness of the "IO hack" when resorting
                   to manual state token threading and direct use of primops.
                   More details below.
      - `T13380e`: Demonstrating unsoundness of the "IO hack" when we have
                   Nested CPR. Not currently relevant, as we don't have Nested
                   CPR yet.
      - `T13380f`: Demonstrating unsound...
      9bd20e83
  7. 14 May, 2020 1 commit
    • Artem Pelenitsyn's avatar
      Don't reload environment files on every setSessionDynFlags · d880d6b2
      Artem Pelenitsyn authored
      Makes `interpretPackageEnv` (which loads envirinment files) a part of
      `parseDynamicFlags` (parsing command-line arguments, which is typically
      done once) instead of `setSessionDynFlags` (which is typically called
      several times). Making several (transitive) calls to `interpretPackageEnv`,
      as before, caused #18125 #16318, which should be fixed now.
      d880d6b2
  8. 04 May, 2020 1 commit
  9. 01 May, 2020 2 commits
    • Sylvain Henry's avatar
      Remove PprStyle param of logging actions · b3df9e78
      Sylvain Henry authored
      Use `withPprStyle` instead to apply a specific style to a SDoc.
      b3df9e78
    • Sylvain Henry's avatar
      Refactor PprDebug handling · f8386c7b
      Sylvain Henry authored
      If `-dppr-debug` is set, then PprUser and PprDump styles are silently
      replaced with PprDebug style. This was done in `mkUserStyle` and
      `mkDumpStyle` smart constructors. As a consequence they needed a
      DynFlags parameter.
      
      Now we keep the original PprUser and PprDump styles until they are used
      to create an `SDocContext`. I.e. the substitution is only performed in
      `initSDocContext`.
      f8386c7b
  10. 30 Apr, 2020 2 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
  11. 26 Apr, 2020 1 commit
  12. 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
  13. 07 Apr, 2020 1 commit
  14. 29 Mar, 2020 1 commit
  15. 17 Mar, 2020 1 commit
  16. 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 interpreterDynamic and interpreterProfiled · bc41e471
      Sylvain Henry authored
      * `interpreterDynamic` and `interpreterProfiled` now take `Interp`
        parameters instead of DynFlags
      
      * slight refactoring of `ExternalInterp` so that we can read the iserv
        configuration (which is pure) without reading an MVar.
      bc41e471
  17. 29 Feb, 2020 2 commits
    • Sylvain Henry's avatar
      Refactor runtime interpreter code · 18757cab
      Sylvain Henry authored
      In #14335 we want to be able to use both the internal interpreter (for
      the plugins) and the external interpreter (for TH and GHCi) at the same
      time.
      
      This patch performs some preliminary refactoring: the `hsc_interp` field
      of HscEnv replaces `hsc_iserv` and is now used to indicate which
      interpreter (internal, external) to use to execute TH and GHCi.
      
      Opt_ExternalInterpreter flag and iserv options in DynFlags are now
      queried only when we set the session DynFlags. It should help making GHC
      multi-target in the future by selecting an interpreter according to the
      selected target.
      18757cab
    • Vladislav Zavialov's avatar
      Monotonic locations (#17632) · 327b29e1
      Vladislav Zavialov authored
      When GHC is parsing a file generated by a tool, e.g. by the C preprocessor, the
      tool may insert #line pragmas to adjust the locations reported to the user.
      
      As the result, the locations recorded in RealSrcLoc are not monotonic. Elements
      that appear later in the StringBuffer are not guaranteed to have a higher
      line/column number.
      
      In fact, there are no guarantees whatsoever, as #line pragmas can arbitrarily
      modify locations. This lack of guarantees makes ideas such as #17544
      infeasible.
      
      This patch adds an additional bit of information to every SrcLoc:
      
      	newtype BufPos = BufPos { bufPos :: Int }
      
      A BufPos represents the location in the StringBuffer, unaffected by any
      pragmas.
      
      Updates haddock submodule.
      
      Metric Increase:
          haddock.Cabal
          haddock.base
          haddock.compiler
          MultiLayerModules
          Naperian
          parsing001
          T12150
      327b29e1
  18. 26 Feb, 2020 1 commit
  19. 24 Feb, 2020 1 commit
    • Vladislav Zavialov's avatar
      Remove Ord SrcLoc, Ord SrcSpan · 26e8fff3
      Vladislav Zavialov authored
      Before this patch, GHC relied on Ord SrcSpan to identify source elements, by
      using SrcSpan as Map keys:
      
      	blackList :: Map SrcSpan ()      -- compiler/GHC/HsToCore/Coverage.hs
      	instanceMap :: Map SrcSpan Name  -- compiler/GHC/HsToCore/Docs.hs
      
      Firstly, this design is not valid in presence of UnhelpfulSpan, as it
      distinguishes between  UnhelpfulSpan "X"  and  UnhelpfulSpan "Y", but those
      strings are messages for the user, unfit to serve as identifiers for source
      elements.
      
      Secondly, this design made it hard to extend SrcSpan with additional data.
      Recall that the definition of SrcSpan is:
      
      	data SrcSpan =
      	    RealSrcSpan !RealSrcSpan
      	  | UnhelpfulSpan !FastString
      
      Say we want to extend the RealSrcSpan constructor with additional information:
      
      	data SrcSpan =
      	    RealSrcSpan !RealSrcSpan !AdditionalInformation
      	  | UnhelpfulSpan !FastString
      
      	getAdditionalInformation :: SrcSpan -> AdditionalInformation
      	getAdditionalInformation (RealSrcSpan _ a) = a
      
      Now, in order for  Map SrcSpan  to keep working correctly, we must *ignore* additional
      information when comparing SrcSpan values:
      
      	instance Ord SrcSpan where
      	  compare (RealSrcSpan r1 _) (RealSrcSpan r2 _) = compare r1 r2
      	  ...
      
      However, this would violate an important law:
      
      	a == b  therefore  f a == f b
      
      Ignoring  AdditionalInformation  in comparisons would mean that with
      f=getAdditionalInformation, the law above does not hold.
      
      A more robust design is to avoid  Ord SrcSpan  altogether, which is what this patch implements.
      The mappings are changed to use RealSrcSpan instead:
      
      	blackList :: Set RealSrcSpan         -- compiler/GHC/HsToCore/Coverage.hs
      	instanceMap :: Map RealSrcSpan Name  -- compiler/GHC/HsToCore/Docs.hs
      
      All SrcSpan comparisons are now done with explicit comparison strategies:
      
      	SrcLoc.leftmost_smallest
      	SrcLoc.leftmost_largest
      	SrcLoc.rightmost_smallest
      
      These strategies are not subject to the law mentioned above and can easily
      discard both the string stored in  UnhelpfulSpan  and  AdditionalInformation.
      
      Updates haddock submodule.
      26e8fff3
  20. 22 Feb, 2020 2 commits
    • Sylvain Henry's avatar
      Modules: Driver (#13009) · 240f5bf6
      Sylvain Henry authored
      submodule updates: nofib, haddock
      240f5bf6
    • Vladislav Zavialov's avatar
      Parser API annotations: RealSrcLoc · be7068a6
      Vladislav Zavialov authored
      During parsing, GHC collects lexical information about AST nodes and
      stores it in a map. It is needed to faithfully restore original source
      code, e.g. compare these expressions:
      
      	a =  b
      	a  = b
      
      The position of the equality sign is not recorded in the AST, so it must
      be stored elsewhere.
      
      This system is described in Note [Api annotations].
      
      Before this patch, the mapping was represented by:
      
      	Map (SrcSpan, AnnKeywordId) SrcSpan
      
      After this patch, the mapping is represented by:
      
      	Map (RealSrcSpan, AnnKeywordId) RealSrcSpan
      
      The motivation behind this change is to avoid using the Ord SrcSpan
      instance (required by Map here), as it interferes with #17632 (see the
      discussion there).
      
      SrcSpan is isomorphic to  Either String RealSrcSpan,  but we shouldn't
      use those strings as Map keys. Those strings are intended as hints to
      the user, e.g. "<interactive>" or "<compiler-generated code>", so they
      are not a valid way to identify nodes in the source code.
      be7068a6
  21. 19 Feb, 2020 1 commit
  22. 12 Feb, 2020 1 commit
  23. 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
  24. 07 Jan, 2020 1 commit
    • Ryan Scott's avatar
      Monomorphize HsModule to GhcPs (#17642) · b69a3460
      Ryan Scott authored
      Analyzing the call sites for `HsModule` reveals that it is only ever
      used with parsed code (i.e., `GhcPs`). This simplifies `HsModule` by
      concretizing its `pass` parameter to always be `GhcPs`.
      
      Fixes #17642.
      b69a3460
  25. 06 Jan, 2020 1 commit
  26. 04 Jan, 2020 1 commit
  27. 17 Dec, 2019 1 commit
  28. 30 Nov, 2019 1 commit
  29. 13 Nov, 2019 1 commit
    • Ben Gamari's avatar
      Ensure that coreView/tcView are able to inline · 2d4f9ad8
      Ben Gamari authored
      Previously an import cycle between Type and TyCoRep meant that several
      functions in TyCoRep ended up SOURCE import coreView. This is quite
      unfortunate as coreView is intended to be fused into a larger pattern
      match and not incur an extra call.
      
      Fix this with a bit of restructuring:
      
       * Move the functions in `TyCoRep` which depend upon things in `Type`
         into `Type`
       * Fold contents of `Kind` into `Type` and turn `Kind` into a simple
         wrapper re-exporting kind-ish things from `Type`
       * Clean up the redundant imports that popped up as a result
      
      Closes #17441.
      
      Metric Decrease:
          T4334
      2d4f9ad8
  30. 16 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Break up TcRnTypes, among other modules. · 51fad9e6
      Richard Eisenberg authored
      This introduces three new modules:
      
       - basicTypes/Predicate.hs describes predicates, moving
         this logic out of Type. Predicates don't really exist
         in Core, and so don't belong in Type.
      
       - typecheck/TcOrigin.hs describes the origin of constraints
         and types. It was easy to remove from other modules and
         can often be imported instead of other, scarier modules.
      
       - typecheck/Constraint.hs describes constraints as used in
         the solver. It is taken from TcRnTypes.
      
      No work other than module splitting is in this patch.
      
      This is the first step toward homogeneous equality, which will
      rely more strongly on predicates. And homogeneous equality is the
      next step toward a dependently typed core language.
      51fad9e6