.. _release-8-10-1:
Release notes for version 8.10.1
================================
The significant changes to the various parts of the compiler are listed in the
following sections.
Highlights
----------
- The :extension:`UnliftedNewtypes` extension, allowing ``newtype``\s to be
wrap types of kind other than ``Type``.
- The :extension:`StandaloneKindSignatures` extension, allowing explicit
signatures on type constructors.
- A new, :rts-flag:`low-latency garbage collector <-xn>` for the oldest generation.
Full details
------------
Language
~~~~~~~~
- Kind variables are no longer implicitly quantified when an explicit ``forall`` is used, see
`GHC proposal #24
<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst>`__.
:ghc-flag:`-Wimplicit-kind-vars` is now obsolete.
- Kind variables are no longer implicitly quantified in constructor declarations: ::
data T a = T1 (S (a :: k)) | forall (b::k). T2 (S b) -- no longer accepted
data T (a :: k) = T1 (S (a :: k)) | forall (b::k). T2 (S b) -- still accepted
- Implicitly quantified kind variables are no longer put in front of other variables: ::
f :: Proxy (a :: k) -> Proxy (b :: j)
ghci> :t +v f -- old order:
f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b
ghci> :t +v f -- new order:
f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b
This is a breaking change for users of :extension:`TypeApplications`.
- In type synonyms and type family equations, free variables on the RHS are no longer
implicitly quantified unless used in an outermost kind annotation: ::
type T = Just (Nothing :: Maybe a) -- no longer accepted
type T = Just Nothing :: Maybe (Maybe a) -- still accepted
- A new extension :extension:`StandaloneKindSignatures` allows one to explicitly
specify the kind of a type constructor, as proposed in `GHC proposal #54
<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0054-kind-signatures.rst>`__: ::
type TypeRep :: forall k. k -> Type
data TypeRep a where
TyInt :: TypeRep Int
TyMaybe :: TypeRep Maybe
TyApp :: TypeRep a -> TypeRep b -> TypeRep (a b)
Analogous to function type signatures, a :ref:`standalone kind signature
<standalone-kind-signatures>` enables polymorphic recursion. This feature is
a replacement for :extension:`CUSKs`.
**Note:** The finer points around this feature are subject to change. In particular,
it is likely that the treatment around :ref:`specified and inferred <inferred-vs-specified>`
variables may change, to become more like the way term-level type signatures are
handled.
- GHC now parses visible, dependent quantifiers (as proposed in
`GHC proposal 35
<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0081-forall-arrow.rst>`__),
such as the following: ::
data Proxy :: forall k -> k -> Type
See the :ref:`section on explicit kind quantification
<explicit-kind-quantification>` for more details.
- Type variables in associated type family default declarations can now be
explicitly bound with a ``forall`` when :extension:`ExplicitForAll` is
enabled, as in the following example: ::
class C a where
type T a b
type forall a b. T a b = Either a b
This has a couple of knock-on consequences:
- Wildcard patterns are now permitted on the left-hand sides of default
declarations, whereas they were rejected by previous versions of GHC.
- It used to be the case that default declarations supported occurrences of
left-hand side arguments with higher-rank kinds, such as in the following
example: ::
class C a where
type T a (f :: forall k. k -> Type)
type T a (f :: forall k. k -> Type) = f Int
This will no longer work unless ``f`` is explicitly quantified with a
``forall``, like so: ::
class C a where
type T a (f :: forall k. k -> Type)
type forall a (f :: forall k. k -> Type).
T a f = f Int
- A new extension :extension:`UnliftedNewtypes` that relaxes restrictions
around what kinds of types can appear inside of the data constructor
for a ``newtype``. This was proposed in
`GHC proposal #13 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst>`__.
- A new extension :extension:`ImportQualifiedPost` allows the syntax
``import M qualified``, that is, to annotate a module as qualified by
writing ``qualified`` after the module name.
This was proposed in `GHC proposal #49 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0049-module-qualified-syntax.rst>`__.
- New flag :ghc-flag:`-Wderiving-defaults` that controls a warning
message when both :extension:`DeriveAnyClass` and
:extension:`GeneralizedNewtypeDeriving` are enabled and no explicit
deriving strategy is in use. The warning is enabled by default and
has been present in earlier GHC versions but without the option of
disabling it. For example, this code would trigger the warning: ::
class C a
newtype T a = MkT a deriving C
- GHC now performs more validity checks on inferred type signatures. One
consequence of this change is that some programs that used to be accepted
will no longer compile without enabling the required language extensions.
For example, in these two modules: ::
{-# LANGUAGE RankNTypes #-}
module A where
foo :: (forall a. a -> a) -> b -> b
foo f x = f x
module B where
import A
bar = foo
Notice that ``A`` enables :ghc-flag:`-XRankNTypes`, but ``B`` does not.
Previous versions of GHC would allow ``bar`` to typecheck, even though its
inferred type is higher-rank. GHC 8.10 will now reject this, as one must now
enable :ghc-flag:`-XRankNTypes` in ``B`` to accept the inferred type signature.
- Type family dependencies (also known as injective type families)
sometimes now need :ghc-flag:`-XUndecidableInstances` in order to be
accepted. Here is an example::
type family F1 a = r | r -> a
type family F2 a = r | r -> a
type instance F2 [a] = Maybe (F1 a)
Because GHC needs to look under a type family to see that ``a`` is determined
by the right-hand side of ``F2``\'s equation, this now needs :ghc-flag:`-XUndecidableInstances`.
The problem is very much akin to its need to detect some functional dependencies.
- The pattern-match coverage checker received a number of improvements wrt.
correctness and performance.
Checking against user-defined COMPLETE pragmas
"just works" now, so that we could move away from the
`complicated procedure for disambiguation <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#disambiguating-between-multiple-complete-pragmas>`__
we had in place before.
Previously, the checker performed really badly on some inputs and had no
good story for graceful degradation in these situations. These situations
should occur much less frequently now and degradation happens much more
smoothly, while still producing useful, sound results (see
:ghc-flag:`-fmax-pmcheck-models=⟨n⟩`).
Compiler
~~~~~~~~
- The :ghc-flag:`LLVM backend <-fllvm>` of this release is to be used with LLVM 9.
- (x86) Native code generator support for legacy x87 floating point coprocessor
has been removed. From this point forth GHC will only support floating point
via SSE2.
- Add new flags :ghc-flag:`-Wunused-record-wildcards` and
:ghc-flag:`-Wredundant-record-wildcards` which warn users when they have
redundant or unused uses of a record wildcard match.
- Calls to ``memset`` and ``memcpy`` are now unrolled more aggressively
and the produced code is more efficient on x86-64 with added
support for 64-bit ``MOV``\s. In particular, ``setByteArray#`` and
``copyByteArray#`` calls that were not optimized before, now will
be. See :ghc-ticket:`16052`.
- When loading modules that use :extension:`UnboxedTuples` or
:extension:`UnboxedSums` into GHCi, it will now automatically enable
:ghc-flag:`-fobject-code` for these modules and all modules they depend on.
Before this change, attempting to load these modules into the interpreter
would just fail, and the only convenient workaround was to enable
:ghc-flag:`-fobject-code` for all modules. See the
:ref:`GHCi FAQ <ghci-faq>` for further details.
- The eventlog now contains events for biographical and retainer profiling.
The biographical profiling events all appear at the end of the eventlog but
the sample start event contains a timestamp of when the census occurred.
The retainer profiling events are emitted using the standard events.
- The eventlog now records the cost centre stack on each profiler sample. This
enables the ``.prof`` file to be partially reconstructed from the eventlog.
- Add new flag :ghc-flag:`-fkeep-going` which makes the compiler
continue as far as it can despite errors.
- Deprecated flag ``-fwarn-hi-shadowing`` because it was not
implemented correctly, and appears to be largely unused. This flag
will be removed in a later version of GHC.
- Windows bindist has been updated to GCC 9.2 and binutils 2.32. These binaries have
been patched to no longer have have the ``MAX_PATH`` limit. Windows users
should no longer have any issues with long path names.
- Introduce ``DynFlags`` plugins, that allow users to modidy the ``DynFlags``
that GHC is going to use when processing a set of files, from plugins.
They can be used for applying tiny configuration changes, registering hooks
and much more. See the :ref:`user guide <dynflags_plugins>` for
more details as well as an example.
- Deprecated flag ``-fmax-pmcheck-iterations`` in favor of
:ghc-flag:`-fmax-pmcheck-models=⟨n⟩`, which uses a completely different mechanism.
- GHC now writes ``.o`` files atomically, resulting in reduced chances
of truncated files when a build is cancelled or the computer crashes.
This fixes numerous bug reports in Stack and Cabal where GHC was not
able to recover from such situations by itself and users reported having
to clean the build directory.
Other file types are not yet written atomically.
Users that observe related problems should report them on
`GHC issue #14533 <https://gitlab.haskell.org/ghc/ghc/issues/14533>`__.
This fix is part of the
`Stack initiative to get rid of persistent build errors due to non-atomic
file writes across the Haskell tooling ecosystem
<https://github.com/commercialhaskell/stack/issues/4559>`__.
GHC API
~~~~~~~
- GHC's runtime linker no longer uses global state. This allows programs
that use the GHC API to safely use multiple GHC sessions in a single
process, as long as there are no native dependencies that rely on
global state.
- In the process of making GHC's codebase more modular, many modules have been
renamed to better reflect the different phases of the compiler. See
:ghc-ticket:`13009`. Programs that rely on the previous GHC API may use the
`ghc-api-compat <https://hackage.haskell.org/package/ghc-api-compat>`_ package
to make the transition to the new interface easier. The renaming process is
still going on so you must expect other similar changes in the next major
release.
GHCi
~~~~
- Added a command :ghci-cmd:`:instances` to show the class instances available for a type.
- Added new debugger commands :ghci-cmd:`:disable` and :ghci-cmd:`:enable` to
disable and re-enable breakpoints.
- Improved command name resolution with option ``!``. For example, ``:k!``
resolves to ``:kind!``.
Runtime system
~~~~~~~~~~~~~~
- The runtime system linker now marks loaded code as non-writable (see
:ghc-ticket:`14069`) on all tier-1 platforms. This is necesaary for
out-of-the-box compatibility with OpenBSD and macOS Catalina (see
:ghc-ticket:`17353`)
- The RTS API now exposes :ref:`an interface <event_log_output_api>` to
configure ``EventLogWriters``, allowing eventlog data to fed to sinks other
than ``.eventlog`` files.
- A new ``+RTS`` flag ``--disable-delayed-os-memory-return`` was added to make
for accurate resident memory usage of the program as shown in memory
usage reporting tools (e.g. the ``RSS`` column in ``top`` and ``htop``).
This makes it easier to check the real memory usage of Haskell programs.
Using this new flag is expected to make the program slightly slower.
Without this flag, the (Linux) RTS returns unused memory "lazily" to the OS.
This has making the memory available to other processes while also allowing
the RTS to re-use the memory very efficiently (without zeroing pages) in case
it needs it again, but common tools will incorrectly show such memory as
occupied by the RTS (because they do not process the ``LazyFree`` field in
``/proc/PID/smaps``).
Template Haskell
~~~~~~~~~~~~~~~~
- The ``Lift`` typeclass is now levity-polymorphic and has a ``liftTyped``
method. Previously disallowed instances for unboxed tuples, unboxed sums, an
primitive unboxed types have also been added. Finally, the code generated by
:extension:`DeriveLift` has been simplified to take advantage of expression
quotations.
- Using ``TupleT 1``, ``TupE [exp]``, or ``TupP [pat]`` will now produce unary
tuples (i.e., involving the ``Unit`` type from ``GHC.Tuple``) instead of
silently dropping the parentheses. This brings Template Haskell's treatment
of boxed tuples in line with that of unboxed tuples, as ``UnboxedTupleT`,
``UnboxedTupE``, and ``UnboxedTupP`` also produce unary unboxed tuples
(i.e., ``Unit#``) when applied to only one argument.
- GHC's constraint solver now solves constraints in each top-level group
sooner. This has practical consequences for Template Haskell, as TH splices
necessarily separate top-level groups. For example, the following program
would compile in previous versions of GHC, but not in GHC 8.10: ::
data T = MkT
tStr :: String
tStr = show MkT
$(return [])
instance Show T where
show MkT = "MkT"
This is because each top-level group's constraints are solved before moving
on to the next, and since the top-level group for ``tStr`` appears before the
top-level group that defines a ``Show T`` instance, GHC 8.10 will throw an
error about a missing ``Show T`` instance in the expression ``show MkT``. The
issue can be fixed by rearranging the order of declarations. For instance,
the following will compile: ::
data T = MkT
instance Show T where
show MkT = "MkT"
$(return [])
tStr :: String
tStr = show MkT
- TH splices by default don't generate warnings anymore. For example,
``$([d| f :: Int -> void; f x = case x of {} |])`` used to generate a
pattern-match exhaustivity warning, which now it doesn't. The user can
activate warnings for TH splices with :ghc-flag:`-fenable-th-splice-warnings`.
The reason for opt-in is that the offending code might not have been generated
by code the user has control over, for example the ``singletons`` or ``lens``
library.
``ghc-prim`` library
~~~~~~~~~~~~~~~~~~~~
- Add new ``bitReverse#`` primops that, for a ``Word`` of 8, 16, 32 or 64 bits,
reverse the order of its bits e.g. ``0b110001`` becomes ``0b100011``.
These primitives use optimized machine instructions when available.
``ghc`` library
~~~~~~~~~~~~~~~
``base`` library
~~~~~~~~~~~~~~~~
Build system
~~~~~~~~~~~~
- Countless bug fixes in the new Hadrian build system
- Hadrian now supports a simple key-value configuration language, eliminating
the need for users to use Haskell to define build configuration. This should
simplify life for packagers and users alike. See :ghc-ticket:`16769` and the
documentation in ``hadrian/doc/user-settings.md``.
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/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 ``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/libiserv/libiserv.cabal: Internal compiler 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