1. 12 Jul, 2021 1 commit
    • sheaf's avatar
      Generalise reallyUnsafePtrEquality# and use it · cbf6e1de
      sheaf authored
      fixes #9192 and #17126
      updates containers submodule
      1. Changes the type of the primop `reallyUnsafePtrEquality#` to the most
      general version possible (heterogeneous as well as levity-polymorphic):
      > reallyUnsafePtrEquality#
      >   :: forall {l :: Levity} {k :: Levity}
      >        (a :: TYPE (BoxedRep l)) (b :: TYPE (BoxedRep k))
      >   . a -> b -> Int#
      2. Adds a new internal module, `GHC.Ext.PtrEq`, which contains pointer
      equality operations that are now subsumed by `reallyUnsafePtrEquality#`.
      These functions are then re-exported by `GHC.Exts` (so that no function
      goes missing from the export list of `GHC.Exts`, which is user-facing).
      More specifically, `GHC.Ext.PtrEq` defines:
        - A new function:
          * reallyUnsafePtrEquality :: forall (a :: Type). a -> a -> Int#
        - Library definitions of ex-primops:
           * `sameMutableArray#`
           * `sameSmallMutableArray`
           * `sameMutableByteArray#`
           * `sameMutableArrayArray#`
           * `sameMutVar#`
           * `sameTVar#`
           * `sameMVar#`
           * `sameIOPort#`
           * `eqStableName#`
        - New functions for comparing non-mutable arrays:
           * `sameArray#`
           * `sameSmallArray#`
           * `sameByteArray#`
           * `sameArrayArray#`
        These were requested in #9192.
      Generally speaking, existing libraries that
      use `reallyUnsafePtrEquality#` will continue to work with the new,
      levity-polymorphic version. But not all!
      Some (`containers`, `unordered-containers`, `dependent-map`) contain
      the following:
      > unsafeCoerce# reallyUnsafePtrEquality# a b
      If we make `reallyUnsafePtrEquality#` levity-polymorphic, this code
      fails the current GHC representation-polymorphism checks.
      We agreed that the right solution here is to modify the library;
      in this case by deleting the call to `unsafeCoerce#`,
      since `reallyUnsafePtrEquality#` is now type-heterogeneous too.
  2. 10 Jul, 2021 2 commits
  3. 09 Jul, 2021 15 commits
  4. 08 Jul, 2021 1 commit
  5. 07 Jul, 2021 2 commits
    • Matthew Pickering's avatar
      driver: Add test for #12983 · 5a31abe3
      Matthew Pickering authored
      This test has worked since 8.10.2 at least but was recently broken and
      is now working again after this patch.
      Closes #12983
    • Matthew Pickering's avatar
      driver: Convert runPipeline to use a free monad · 421beb3f
      Matthew Pickering authored
      This patch converts the runPipeline function to be implemented in terms
      of a free monad rather than the previous CompPipeline.
      The advantages of this are three-fold:
      1. Different parts of the pipeline can return different results, the
      limits of runPipeline were being pushed already by !5555, this opens up
      futher fine-grainedism of the pipeline.
      2. The same mechanism can be extended to build-plan at the module level
      so the whole build plan can be expressed in terms of one computation
      which can then be treated uniformly.
      3. The pipeline monad can now be interpreted in different ways, for
      example, you may want to interpret the `TPhase` action into the monad
      for your own build system (such as shake). That bit will probably
      require a bit more work, but this is a step in the right directin.
      There are a few more modules containing useful functions for interacting
      with the pipelines.
      * GHC.Driver.Pipeline: Functions for building pipelines at a high-level
      * GHC.Driver.Pipeline.Execute: Functions for providing the default
      interpretation of TPhase, in terms of normal IO.
      * GHC.Driver.Pipeline.Phases: The home for TPhase, the typed phase data
      type which dictates what the phases are.
      * GHC.Driver.Pipeline.Monad: Definitions to do with the TPipelineClass
      and MonadUse class.
      Hooks consumers may notice the type of the `phaseHook` has got
      slightly more restrictive, you can now no longer control the
      continuation of the pipeline by returning the next phase to execute but
      only override individual phases. If this is a problem then please open
      an issue and we will work out a solution.
      Metric Decrease:
  6. 06 Jul, 2021 6 commits
    • Andreas Klebinger's avatar
      Fix #19889 - Invalid BMI2 instructions generated. · 6618008b
      Andreas Klebinger authored
      When arguments are 8 *or 16* bits wide, then truncate before/after
      and use the 32bit operation.
    • CSEdd's avatar
      Fix issue 20038 - Change 'variable' -> 'variables' · 17091114
      CSEdd authored
    • Sylvain Henry's avatar
      Use target platform in guessOutputFile · 354ac99d
      Sylvain Henry authored
    • Ethan Kiang's avatar
      Pass '-x c++' and '-std=c++11' to `cc` for cpp files, in Hadrian · 4002bd1d
      Ethan Kiang authored
      '-x c++' was found to be required on Darwin Clang 11 and 12.
      '-std=c++' was found to be needed on Clang 12 but not 11.
    • Fraser Tweedale's avatar
      Add test for executablePath · a4e742c5
      Fraser Tweedale authored
    • Fraser Tweedale's avatar
      Implement improved "get executable path" query · 4b4c5e43
      Fraser Tweedale authored
      System.Environment.getExecutablePath has some problems:
      - Some system-specific implementations throw an exception in some
        scenarios, e.g. when the executable file has been deleted
      - The Linux implementation succeeds but returns an invalid FilePath
        when the file has been deleted.
      - The fallback implementation returns argv[0] which is not
        necessarily an absolute path, and is subject to manipulation.
      - The documentation does not explain any of this.
      Breaking the getExecutablePath API or changing its behaviour is not
      an appealing direction.  So we will provide a new API.
      There are two facets to the problem of querying the executable path:
      1. Does the platform provide a reliable way to do it?  This is
         statically known.
      2. If so, is there a valid answer, and what is it?  This may vary,
         even over the runtime of a single process.
      Accordingly, the type of the new mechanism is:
        Maybe (IO (Maybe FilePath))
      This commit implements this mechanism, defining the query action for
      FreeBSD, Linux, macOS and Windows.
      Fixes: #10957
      Fixes: #12377
  7. 03 Jul, 2021 2 commits
    • Sebastian Graf's avatar
      Arity: Handle shadowing properly · 9b1d9cbf
      Sebastian Graf authored
      In #20070, we noticed that `findRhsArity` copes badly with shadowing.
      A simple function like `g_123 x_123 = x_123`, where the labmda binder shadows,
      already regressed badly.
      Indeed, the whole `arityType` function wasn't thinking about shadowing *at all*.
      I rectified that and established the invariant that `ae_join` and `am_sigs`
      should always be disjoint. That entails deleting bindings from `ae_join`
      whenever we add something to `am_sigs` and vice versa, which would otherwise be
      a bug in the making.
      That *should* fix (but I don't want to close it) #20070.
    • Luite Stegeman's avatar
      Support unlifted datatypes in GHCi · 5e30451d
      Luite Stegeman authored
      fixes #19628
  8. 02 Jul, 2021 5 commits
  9. 01 Jul, 2021 6 commits