[Git][ghc/ghc][wip/ghc-9.8] 2 commits: Bump array submodule to v0.5.6.0
Ben Gamari (@bgamari)
gitlab at gitlab.haskell.org
Wed Jul 19 17:54:54 UTC 2023
Ben Gamari pushed to branch wip/ghc-9.8 at Glasgow Haskell Compiler / GHC
Commits:
68cc675d by Ben Gamari at 2023-07-19T13:54:38-04:00
Bump array submodule to v0.5.6.0
- - - - -
7063b2a5 by Ben Gamari at 2023-07-19T13:54:38-04:00
users guide: Fix release notes and other documentation issues
- - - - -
5 changed files:
- − docs/users_guide/9.6.1-notes.rst
- docs/users_guide/9.8.1-notes.rst
- docs/users_guide/exts/implicit_parameters.rst
- docs/users_guide/ghc_config.py.in
- libraries/containers
Changes:
=====================================
docs/users_guide/9.6.1-notes.rst deleted
=====================================
@@ -1,264 +0,0 @@
-.. _release-9-6-1:
-
-Version 9.6.1
-==============
-
-Language
-~~~~~~~~
-
-- GHC is now more conservative when solving constraints that arise from
- superclass expansion in terms of other constraints that also arise from
- superclass expansion.
-
- For example: ::
-
- class C a
- class C a => D a b
- instance D a a => D a b
-
- When typechecking the instance, we need to also solve the constraints arising
- from the superclasses of ``D``; in this case, we need ``C a``. We could obtain
- evidence for this constraint by expanding the superclasses of the context,
- as ``D a a`` also has a superclass context of ``C a``.
- However, is it unsound to do so in general, as we might be assuming precisely
- the predicate we want to prove! This can lead to programs that loop at runtime.
-
- When such potentially-loopy situations arise, GHC now emits a warning.
- In future releases, this behaviour will no longer be supported, and the
- typechecker will outright refuse to solve these constraints, emitting a
- ``Could not deduce`` error.
-
- In practice, you should be able to fix these issues by adding the necessary
- constraint to the context, e.g. for the above example: ::
-
- instance (C a, D a a) => D a b
-
-- Record updates for GADTs and other existential datatypes are now
- fully supported.
-
- For example: ::
-
- data D b where
- MkD :: { fld1 :: a -> a, fld2 :: a -> (), fld3 :: b } -> D b
-
- foo :: D b -> D b
- foo d = d { fld1 = id, fld2 = const () }
-
- In this example, we have an existential variable ``a``, and we update
- all fields whose type involves ``a`` at once, so the update is valid.
-
- A side-effect of this change is that GHC now rejects some record updates
- involving fields whose types contain type families (these record updates
- were previously erroneously accepted).
-
- Example: ::
-
- type family F a where
- F Int = Char
- F Float = Char
-
- data T b = MkT { x :: [Int], y :: [F b] }
-
- emptyT :: forall b. T b
- emptyT = MkT [] []
-
- bar :: T Int
- bar = emptyT { x = [3] }
-
- In this example, we can't infer the type of ``emptyT`` in ``bar``: it could be
- ``T Int``, but it could also be ``T Float`` because the type family ``F``
- is not injective and ``T Float ~ T Int``. Indeed, the following typechecks ::
-
- baz :: T Int
- baz = case ( emptyT :: T Float ) of { MkT _ y -> MkT [3] y }
-
- This means that the type of ``emptyT`` is ambiguous in the definition
- of ``bar`` above, and thus GHC rejects the record update: ::
-
- Couldn't match type `F b0' with `Char'
- Expected: [F Int]
- Actual: [F b0]
- NB: ‘F’ is a non-injective type family
- The type variable ‘b0’ is ambiguous
-
- To fix these issues, add a type signature to the expression that the
- record update is applied to (``emptyT`` in the example above), or
- add an injectivity annotation to the type family in the case that
- the type family is in fact injective.
-
-- Error messages are now assigned unique error codes, of the form ``[GHC-12345]``.
-
-- GHC Proposal `#106
- <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0106-type-data.rst>`_
- has been implemented, introducing a new language extension
- :extension:`TypeData`. This extension permits ``type data`` declarations
- as a more fine-grained alternative to :extension:`DataKinds`.
-
-- GHC now does a better job of solving constraints in the presence of multiple
- matching quantified constraints. For example, if we want to solve
- ``C a b Int`` and we have matching quantified constraints: ::
-
- forall x y z. (Ord x, Enum y, Num z) => C x y z
- forall u v. (Enum v, Eq u) => C u v Int
-
- Then GHC will use the second quantified constraint to solve ``C a b Int``,
- as it has a strictly weaker precondition.
-
-- GHC proposal `#170 Unrestricted OverloadedLabels
- <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-unrestricted-overloadedlabels.rst>`_
- has been implemented.
- This extends the variety syntax for constructing labels under :extension:`OverloadedLabels`.
- Examples of newly allowed syntax:
- - Leading capital letters: `#Foo` equivalant to `getLabel @"Foo"`
- - Numeric characters: `#1728` equivalent to `getLabel @"1728"`
- - Arbitrary strings: `#"Hello, World!"` equivalent to `getLabel @"Hello, World!"`
-
-Compiler
-~~~~~~~~
-
-- The `WebAssembly backend
- <https://www.tweag.io/blog/2022-11-22-wasm-backend-merged-in-ghc>`_
- has been merged. This allows GHC to be built as a cross-compiler
- that targets ``wasm32-wasi`` and compiles Haskell code to
- self-contained WebAssembly modules that can be executed on a variety
- of different runtimes. There are a few caveats to be aware of:
-
- - To use the WebAssembly backend, one would need to follow the
- instructions on `ghc-wasm-meta
- <https://gitlab.haskell.org/ghc/ghc-wasm-meta>`_. The WebAssembly
- backend is not included in the GHC release bindists for the time
- being, nor is it supported by ``ghcup`` or ``stack`` yet.
- - The WebAssembly backend is still under active development. It's
- presented in this GHC version as a technology preview, bugs and
- missing features are expected.
-
-- The JavaScript backend has been merged. GHC is now able to be built as a
- cross-compiler targeting the JavaScript platform. The backend should be
- considered a technology preview. As such it is not ready for use in
- production, is not distributed in the GHC release bindists and requires the
- user to manually build GHC as a cross-compiler. See the JavaScript backend
- `wiki <https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend>`_ page
- on the GHC wiki for the current status, project roadmap, build instructions
- and demos.
-
-- The :extension:`TypeInType` is now marked as deprecated. Its meaning has been included
- in :extension:`PolyKinds` and :extension:`DataKinds`.
-
-- The :ghc-flag:`-Woperator-whitespace` warning no longer ignores constructor symbols
- (operators starting with ``:``).
-
-- The :ghc-flag:`-Wstar-is-type` warning is now enabled by default.
-
-GHCi
-~~~~
-
-- GHCi will now accept any file-header pragmas it finds, such as
- ``{-# OPTIONS_GHC ... #-}`` and ``{-# LANGUAGE ... #-}`` (see :ref:`pragmas`). For example,
- instead of using :ghci-cmd:`:set` to enable :ghc-flag:`-Wmissing-signatures`,
- you could instead write:
-
- .. code-block:: none
-
- ghci> {-# OPTIONS_GHC -Wmissing-signatures #-}
-
-This can be convenient when pasting large multi-line blocks of code into GHCi.
-
-Runtime system
-~~~~~~~~~~~~~~
-
-- The `Delimited continuation primops <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0313-delimited-continuation-primops.rst>`_
- proposal has been implemented, adding native support for first-class,
- delimited continuations to the RTS. For the reasons given in the proposal,
- no safe API to access this functionality is provided anywhere in ``base``.
- Instead, the ``prompt#`` and ``control0#`` primops are intended to be consumed
- by library authors directly, who may wrap them a safe API that maintains the
- necessary invariants. See the documentation in ``GHC.Prim`` for more details.
-
-- The behaviour of the ``-M`` flag has been made more strict. It will now trigger
- a heap overflow if the total amount of memory used by the Haskell heap exceeds the limit.
- Previously only live blocks were taken into account.
- This makes it more likely to trigger promptly when the heap is highly fragmented.
-
-- Fixed a bug that sometimes caused live sparks to be GC'ed too early either during
- minor GC or major GC with workstealing disabled. See #22528.
-
-
-``base`` library
-~~~~~~~~~~~~~~~~
-
-- Exceptions thrown by weak pointer finalizers can now be reported by setting
- a global exception handler, using ``GHC.Weak.Finalize.setFinalizerExceptionHandler``.
- The default behaviour is unchanged (exceptions are ignored and not reported).
-
-- GHC now provides a set of operations for introspecting on the threads of a
- program, ``GHC.Conc.listThreads``, as well as operations for querying a thread's
- label (:base-ref:`GHC.Conc.Sync.threadLabel`) and status
- (:base-ref:`GHC.Conc.threadStatus`).
-
-- Change default ``Ord`` implementation of ``(>=)``, ``(>)``, and ``(<)`` to use
- ``(<=)`` instead of ``compare`` per CLC proposal:
- https://github.com/haskell/core-libraries-committee/issues/24
-
-- Updated to `Unicode 15.0.0 <https://www.unicode.org/versions/Unicode15.0.0/>`_.
-
-- Add standard Unicode case predicates :base-ref:`Data.Char.isUpperCase` and
- :base-ref:`Data.Char.isLowerCase`. These predicates use the standard Unicode
- case properties and are more intuitive than :base-ref:`Data.Char.isUpper` and
- :base-ref:`Data.Char.isLower`.
-
-``ghc-prim`` library
-~~~~~~~~~~~~~~~~~~~~
-
-``ghc`` library
-~~~~~~~~~~~~~~~
-
-- Add `Foreign.C.Types.ConstPtr` was added to encode ``const``-qualified pointer return
- types in foreign declarations when using ``CApiFFI`` extension.
-
-``ghc-heap`` library
-~~~~~~~~~~~~~~~~~~~~
-
-
-Included libraries
-------------------
-
-The package database provided with this distribution also contains a number of
-packages other than GHC itself. See the changelogs provided with these packages
-for further change information.
-
-.. ghc-package-list::
-
- libraries/array/array.cabal: Dependency of ``ghc`` library
- libraries/base/base.cabal: Core library
- libraries/binary/binary.cabal: Dependency of ``ghc`` library
- libraries/bytestring/bytestring.cabal: Dependency of ``ghc`` library
- libraries/Cabal/Cabal/Cabal.cabal: Dependency of ``ghc-pkg`` utility
- libraries/Cabal/Cabal-syntax/Cabal-syntax.cabal: Dependency of ``ghc-pkg`` utility
- libraries/containers/containers/containers.cabal: Dependency of ``ghc`` library
- libraries/deepseq/deepseq.cabal: Dependency of ``ghc`` library
- libraries/directory/directory.cabal: Dependency of ``ghc`` library
- libraries/exceptions/exceptions.cabal: Dependency of ``ghc`` and ``haskeline`` library
- libraries/filepath/filepath.cabal: Dependency of ``ghc`` library
- compiler/ghc.cabal: The compiler itself
- libraries/ghci/ghci.cabal: The REPL interface
- libraries/ghc-boot/ghc-boot.cabal: Internal compiler library
- libraries/ghc-boot-th/ghc-boot-th.cabal: Internal compiler library
- libraries/ghc-compact/ghc-compact.cabal: Core library
- libraries/ghc-heap/ghc-heap.cabal: GHC heap-walking library
- libraries/ghc-prim/ghc-prim.cabal: Core library
- libraries/haskeline/haskeline.cabal: Dependency of ``ghci`` executable
- libraries/hpc/hpc.cabal: Dependency of ``hpc`` executable
- libraries/integer-gmp/integer-gmp.cabal: Core library
- libraries/mtl/mtl.cabal: Dependency of ``Cabal`` library
- libraries/parsec/parsec.cabal: Dependency of ``Cabal`` library
- libraries/pretty/pretty.cabal: Dependency of ``ghc`` library
- libraries/process/process.cabal: Dependency of ``ghc`` library
- libraries/stm/stm.cabal: Dependency of ``haskeline`` library
- libraries/template-haskell/template-haskell.cabal: Core library
- libraries/terminfo/terminfo.cabal: Dependency of ``haskeline`` library
- libraries/text/text.cabal: Dependency of ``Cabal`` library
- libraries/time/time.cabal: Dependency of ``ghc`` library
- libraries/transformers/transformers.cabal: Dependency of ``ghc`` library
- libraries/unix/unix.cabal: Dependency of ``ghc`` library
- libraries/Win32/Win32.cabal: Dependency of ``ghc`` library
- libraries/xhtml/xhtml.cabal: Dependency of ``haddock`` executable
=====================================
docs/users_guide/9.8.1-notes.rst
=====================================
@@ -3,21 +3,16 @@
Version 9.8.1
=============
-Language
-~~~~~~~~
-
-- There is a new extension :extension:`ExtendedLiterals`, which enables
- sized primitive literals, e.g. ``123#Int8`` is a literal of type ``Int8#``.
- See the GHC proposal `#451 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst>`_.
+The significant changes to the various parts of the compiler are listed in the
+following sections. See the `migration guide
+<https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8>`_ on the GHC Wiki
+for specific guidance on migrating programs to this release.
-- GHC Proposal `#425
- <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>`_
- has been partially implemented. Namely, the ``@k``-binders in type declarations are now permitted::
-
- type T :: forall k. k -> forall j. j -> Type
- data T @k (a :: k) @(j :: Type) (b :: j)
+The :ghc-flag:`LLVM backend <-fllvm>` of this release is to be used with LLVM
+11, 12, 13, 14 or 15.
- This feature is guarded behind :extension:`TypeAbstractions`.
+Breaking changes
+~~~~~~~~~~~~~~~~
- In accordance with GHC proposal `#425
<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>`_
@@ -35,6 +30,49 @@ Language
type instance forall j . F1 Int = Any :: j -> j
+- Data types with ``deriving`` clauses now reject inferred instance contexts
+ that mention ``TypeError`` constraints (see :ref:`custom-errors`), such as
+ this one: ::
+
+ newtype Foo = Foo Int
+
+ class Bar a where
+ bar :: a
+
+ instance (TypeError (Text "Boo")) => Bar Foo where
+ bar = undefined
+
+ newtype Baz = Baz Foo
+ deriving Bar
+
+ Here, the derived ``Bar`` instance for ``Baz`` would look like this: ::
+
+ instance TypeError (Text "Boo") => Bar Baz
+
+ While GHC would accept this before, GHC 9.8 now rejects it, emitting "``Boo``"
+ in the resulting error message. If you really want to derive this instance and
+ defer the error to sites where the instance is used, you must do so manually
+ with :extension:`StandaloneDeriving`, e.g. ::
+
+ deriving instance TypeError (Text "Boo") => Bar Baz
+
+
+Language
+~~~~~~~~
+
+- There is a new extension :extension:`ExtendedLiterals`, which enables
+ sized primitive numeric literals, e.g. ``123#Int8`` is a literal of type ``Int8#``.
+ See the GHC proposal `#451 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst>`_.
+
+- GHC Proposal `#425
+ <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>`_
+ has been partially implemented. Namely, the ``@k``-binders in type declarations are now permitted::
+
+ type T :: forall k. k -> forall j. j -> Type
+ data T @k (a :: k) @(j :: Type) (b :: j)
+
+ This feature is guarded behind :extension:`TypeAbstractions`.
+
Compiler
~~~~~~~~
@@ -58,9 +96,9 @@ Compiler
- Incoherent instance applications are no longer specialised. The previous implementation of
specialisation resulted in nondeterministic instance resolution in certain cases, breaking
- the specification described in the documentation of the `INCOHERENT` pragma. See :ghc-ticket:`22448` for further details.
+ the specification described in the documentation of the :pragma:`INCOHERENT` pragma. See :ghc-ticket:`22448` for further details.
-- Fix a bug in TH causing excessive calls to ``setNumCapabilities`` when ``-j`` is greater than ``-N``.
+- Fix a bug in TemplateHaskell evaluation causing excessive calls to ``setNumCapabilities`` when :ghc-flag:`-j` is greater than :rts-flag:`-N`.
See :ghc-ticket:`23049`.
- The ``-Wno-⟨wflag⟩``, ``-Werror=⟨wflag⟩`` and ``-Wwarn=⟨wflag⟩`` options are
@@ -86,45 +124,21 @@ Compiler
blah x = x { foo = 5, bar = 6 }
- The point is that only the type S has a constructor with both fields "foo"
- and "bar", so this record update is unambiguous.
-
-- Data types with ``deriving`` clauses now reject inferred instance contexts
- that mention ``TypeError`` constraints (see :ref:`custom-errors`), such as
- this one: ::
-
- newtype Foo = Foo Int
-
- class Bar a where
- bar :: a
-
- instance (TypeError (Text "Boo")) => Bar Foo where
- bar = undefined
-
- newtype Baz = Baz Foo
- deriving Bar
-
- Here, the derived ``Bar`` instance for ``Baz`` would look like this: ::
-
- instance TypeError (Text "Boo") => Bar Baz
+ The point is that only the type S has a constructor with both fields ``foo``
+ and ``bar``, so this record update is unambiguous.
- While GHC would accept this before, GHC 9.8 now rejects it, emitting "``Boo``"
- in the resulting error message. If you really want to derive this instance and
- defer the error to sites where the instance is used, you must do so manually
- with :extension:`StandaloneDeriving`, e.g. ::
-
- deriving instance TypeError (Text "Boo") => Bar Baz
-
-- GHC Proposal `#540 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst`_ has been implemented.
- This adds the `-jsem`:ghc-flag: flag, which instructs GHC to act as a jobserver client.
+- GHC Proposal `#540 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst>`_ has been implemented.
+ This adds the :ghc-flag:`-jsem` flag, which instructs GHC to act as a jobserver client.
This enables multiple GHC processes running at once to share system resources
with each other, communicating via the system semaphore specified by
the flag argument.
+ Complementary support for this feature in ``cabal-install`` will come soon.
+
- GHC Proposal `#433
<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst>`_
has been implemented. This adds the class ``Unsatisfiable :: ErrorMessage -> Constraint``
- to the ``GHC.TypeError`` module. Constraints of the form ``Unsatisfiable msg``
+ to the :base-ref:`GHC.TypeError` module. Constraints of the form ``Unsatisfiable msg``
provide a mechanism for custom type errors that reports the errors in a more
predictable behaviour than ``TypeError``, as these constraints are
handled purely during constraint solving.
@@ -137,27 +151,31 @@ Compiler
This allows errors to be reported when users use the instance, even when
type errors are being deferred.
-- GHC is now deals "insoluble Givens" in a consistent way. For example: ::
+- GHC now deals with "insoluble Givens" in a consistent way. For example: ::
k :: (Int ~ Bool) => Int -> Bool
k x = x
- GHC used to accept the contradictory ``Int~Bool`` in the type signature, but reject the ``Int~Bool`` constraint that arises from typechecking the definition itself. Now it accepts both. More details in `GHC ticket #23413 <https://gitlab.haskell.org/ghc/ghc/-/issues/23413>`_, which gives examples of the previous inconsistency. GHC now implements the "PermissivePlan" described in that ticket.
+ GHC used to accept the contradictory ``Int~Bool`` in the type signature, but
+ reject the ``Int~Bool`` constraint that arises from typechecking the
+ definition itself. Now it accepts both. More details in
+ :ghc-ticket:`23413`, which gives examples of the previous inconsistency. GHC
+ now implements the "PermissivePlan" described in that ticket.
-- The `-ddump-spec` flag has been split into `-ddump-spec` and
- `-ddump-spec-constr`, allowing only output from the typeclass specialiser or
- `SpecConstr` to be seen if desired.
+- The :ghc-flag:`-ddump-spec` flag has been split into :ghc-flag:`-ddump-spec` and
+ :ghc-flag:`-ddump-spec-constr`, allowing only output from the typeclass specialiser or
+ data-constructor specialiser to be dumped if desired.
- The compiler may now be configured to compress the debugging information
included in :ghc-flag:`-finfo-table-map` enabled binaries. To do so, one must
build GHC from source (see
- `here<https://gitlab.haskell.org/ghc/ghc/-/wikis/building>` for directions)
+ `here <https://gitlab.haskell.org/ghc/ghc/-/wikis/building>`_ for directions)
and supply the ``--enable-ipe-data-compression`` flag to the ``configure``
script. **Note**: This feature requires that the machine building GHC has
`libzstd <https://github.com/facebook/zstd/>`_ version 1.4.0 or greater
installed. The compression library `libzstd` may optionally be statically
linked in the resulting compiler (on non-darwin machines) using the
- `--enable-static-libzstd` configure flag.
+ ``--enable-static-libzstd`` configure flag.
In a test compiling GHC itself, the size of the :ghc-flag:`-finfo-table-map`
enabled build results was reduced by over 20% when compression was enabled.
@@ -169,11 +187,11 @@ Compiler
For example ::
- module X (
- {-# WARNING "do not use that constructor" D(D1),
- D(D2)
- )
- D = D1 | D2
+ module X
+ ( {-# DEPRECATE D(D1) "D1 will not be exposed in a version 0.2 and later" #-}
+ D(D1, D2)
+ ) where
+ data D = D1 | D2
This allows for changing the structure of a library without immediately breaking user code,
but instead being able to warn the user that a change in the library interface
@@ -182,7 +200,10 @@ Compiler
GHCi
~~~~
-- The deprecated `:ctags` and `:etags` GHCi commands have been removed. See this `wiki page <https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/GHCi/Tags>`_ if you want to add a macro to recover similar functionality.
+- The deprecated ``:ctags`` and ``:etags`` GHCi commands have been removed. See
+ this `wiki page
+ <https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/GHCi/Tags>`_ if you
+ want to add a macro to recover similar functionality.
Runtime system
~~~~~~~~~~~~~~
@@ -193,7 +214,7 @@ Runtime system
``base`` library
~~~~~~~~~~~~~~~~
-- ``Data.Tuple`` now exports ``getSolo :: Solo a -> a``.
+- :base-ref:`Data.Tuple` now exports ``getSolo :: Solo a -> a``.
``ghc-prim`` library
~~~~~~~~~~~~~~~~~~~~
@@ -211,7 +232,7 @@ Runtime system
- New primops for fused multiply-add operations. These primops combine a
multiplication and an addition, compiling to a single instruction when
- the ``-mfma`` flag is enabled and the architecture supports it.
+ the :ghc-flag:`-mfma` flag is enabled and the architecture supports it.
The new primops are ``fmaddFloat#, fmsubFloat#, fnmaddFloat#, fnmsubFloat# :: Float# -> Float# -> Float# -> Float#``
and ``fmaddDouble#, fmsubDouble#, fnmaddDouble#, fnmsubDouble# :: Double# -> Double# -> Double# -> Double#``.
@@ -245,19 +266,16 @@ Runtime system
This represents the warning assigned to a certain export item,
which is used for :ref:`deprecated-exports`.
-``ghc-heap`` library
-~~~~~~~~~~~~~~~~~~~~
-
``template-haskell`` library
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Record fields now belong to separate ``NameSpace``s, keyed by the parent of
+- Record fields now belong to separate ``NameSpace``\ s, keyed by the parent of
the record field. This is the name of the first constructor of the parent type,
even if this constructor does not have the field in question.
- This change enables TemplateHaskell support for ``DuplicateRecordFields``.
+ This change enables :extension:`TemplateHaskell` support for :extension:`DuplicateRecordFields`.
Included libraries
-------------------
+~~~~~~~~~~~~~~~~~~
The package database provided with this distribution also contains a number of
packages other than GHC itself. See the changelogs provided with these packages
@@ -290,6 +308,7 @@ for further change information.
libraries/parsec/parsec.cabal: Dependency of ``Cabal`` library
libraries/pretty/pretty.cabal: Dependency of ``ghc`` library
libraries/process/process.cabal: Dependency of ``ghc`` library
+ libraries/semaphore-compat/semaphore-compat.cabal: Dependency of ``ghc`` library
libraries/stm/stm.cabal: Dependency of ``haskeline`` library
libraries/template-haskell/template-haskell.cabal: Core library
libraries/terminfo/terminfo.cabal: Dependency of ``haskeline`` library
=====================================
docs/users_guide/exts/implicit_parameters.rst
=====================================
@@ -181,7 +181,7 @@ Adding a type signature dramatically changes the result! This is a
rather counter-intuitive phenomenon, worth watching out for.
Implicit parameters scoping guarantees
--------------------------------------
+--------------------------------------
GHC always takes the most nested implicit parameter binding from the
context to find the value. Consider the following code::
=====================================
docs/users_guide/ghc_config.py.in
=====================================
@@ -1,6 +1,6 @@
extlinks = {
- 'ghc-ticket': ('https://gitlab.haskell.org/ghc/ghc/issues/%s', '%s'),
- 'ghc-wiki': ('https://gitlab.haskell.org/ghc/ghc/wikis/%s', '#%s'),
+ 'ghc-ticket': ('https://gitlab.haskell.org/ghc/ghc/issues/%s', '#%s'),
+ 'ghc-wiki': ('https://gitlab.haskell.org/ghc/ghc/wikis/%s', '%s'),
}
libs_base_uri = '../libraries'
=====================================
libraries/containers
=====================================
@@ -1 +1 @@
-Subproject commit f61b0c9104a3c436361f56a0974c5eeef40c1b89
+Subproject commit 8663795322622ac77cc78566185bffbc84e299f2
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/612f17367708d70b6264b85520457789f90be4da...7063b2a5558ef51859eac5a1572fcef79a03b438
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/612f17367708d70b6264b85520457789f90be4da...7063b2a5558ef51859eac5a1572fcef79a03b438
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230719/a737fcc1/attachment-0001.html>
More information about the ghc-commits
mailing list