| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The code
do; a <- doAsync; b
Generated an incorrect Anchor for the statement list that starts after
the first semicolon.
This commit fixes it.
Closes #20256
|
| |
|
|
|
|
|
|
|
|
|
| |
The LaTeX documentation generator does not seem to have been used for
quite some time, so the LaTeX-to-Haddock preprocessing step has become a
pointless complication that makes documenting the contents of GHC.Prim
needlessly difficult. This commit replaces the LaTeX syntax with the
Haddock it would have been converted into, anyway, though with an
additional distinction: it uses single quotes in places to instruct
Haddock to generate hyperlinks to bindings. This improves the quality of
the generated output.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that @JunmingZhao42 and I noticed while working on her
MMTK port. Specifically, in stg_stop_thread we used stg_enter_info as a
sentinel at the tail of a stack after a thread has completed. However,
stg_enter_info expects to have a two-field payload, which we do not
push. Consequently, if the GC ends up somehow the stack it will attempt
to interpret data past the end of the stack as the frame's fields,
resulting in unsound behavior.
To fix this I eliminate this hacky use of `stg_stop_thread` and instead
introduce a new stack frame type, `stg_dead_thread_info`. Not only does
this eliminate the potential for the previously mentioned memory
unsoundness but it also more clearly captures the intended structure of
the dead threads' stacks.
|
| |
|
|
| |
This reverts commit e09afbf2a998beea7783e3de5dce5dd3c6ff23db.
|
| | |
|
| | |
|
| |
|
|
| |
Bumps haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that @JunmingZhao42 and I noticed while working on her
MMTK port. Specifically, in stg_stop_thread we used stg_enter_info as a
sentinel at the tail of a stack after a thread has completed. However,
stg_enter_info expects to have a two-field payload, which we do not
push. Consequently, if the GC ends up somehow the stack it will attempt
to interpret data past the end of the stack as the frame's fields,
resulting in unsound behavior.
To fix this I eliminate this hacky use of `stg_stop_thread` and instead
introduce a new stack frame type, `stg_dead_thread_info`. Not only does
this eliminate the potential for the previously mentioned memory
unsoundness but it also more clearly captures the intended structure of
the dead threads' stacks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Drop libtool logic from gen-dll, allowing us to drop the remaining logic
from the `configure` script.
Strangely, this appears to reliably reduce compiler allocations of
T16875 on Windows.
Closes #18826.
Metric Decrease:
T16875
|
| |
|
|
|
|
| |
One more step towards the new design of EPA.
Updates the haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements a small part of GHC Proposal #475.
The key change is in GHC.Types:
- data [] a = [] | a : [a]
+ data List a = [] | a : List a
And the rest of the patch makes sure that List is pretty-printed as []
in various contexts.
Updates the haddock submodule.
|
| |
|
|
|
| |
-Wuni-incomplete-patterns and apparent improvements in the pattern match
checker surfaced these.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#20385)
Once we are done parsing the header of a module to obtain the options, we
look through the rest of the tokens in order to determine if they contain any
misplaced file header pragmas that would usually be ignored, potentially
resulting in bad error messages.
The warnings are reported immediately so that later errors don't shadow
over potentially helpful warnings.
Metric Increase:
T13719
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit implements proposal 302: \cases - Multi-way lambda
expressions.
This adds a new expression heralded by \cases, which works exactly like
\case, but can match multiple apats instead of a single pat.
Updates submodule haddock to support the ITlcases token.
Closes #20768
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a PromotionFlag field to HsOpTy, which is used
in pretty-printing and when determining whether to emit warnings
with -fwarn-unticked-promoted-constructors.
This allows us to correctly report tick-related warnings for things
like:
type A = Int : '[]
type B = [Int, Bool]
Updates haddock submodule
Fixes #19984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, 'pcPrimTyCon', the function used to define a primitive type,
was taking a PrimRep, only to convert it to a RuntimeRep. Now it takes
a RuntimeRep directly.
Moved primRepToRuntimeRep to GHC.Types.RepType. It is now
located next to its inverse function runtimeRepPrimRep.
Now GHC.Builtin.Types.Prim no longer mentions PrimRep, and GHC.Types.RepType
no longer imports GHC.Builtin.Types.Prim.
Removed unused functions `primRepsToRuntimeRep` and `mkTupleRep`.
Removed Note [PrimRep and kindPrimRep] - it was never referenced,
didn't belong to Types.Prim, and Note [Getting from RuntimeRep to
PrimRep] is more comprehensive.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A new pragma, `OPAQUE`, that ensures that every call of a named
function annotated with an `OPAQUE` pragma remains a call of that
named function, not some name-mangled variant.
Implements GHC proposal 0415:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0415-opaque-pragma.rst
This commit also updates the haddock submodule to handle the newly
introduced lexer tokens corresponding to the OPAQUE pragma.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Names appearing in Haddock docstrings are lexed and renamed like any other names
appearing in the AST. We currently rename names irrespective of the namespace,
so both type and constructor names corresponding to an identifier will appear in
the docstring. Haddock will select a given name as the link destination based on
its own heuristics.
This patch also restricts the limitation of `-haddock` being incompatible with
`Opt_KeepRawTokenStream`.
The export and documenation structure is now computed in GHC and serialised in
.hi files. This can be used by haddock to directly generate doc pages without
reparsing or renaming the source. At the moment the operation of haddock
is not modified, that's left to a future patch.
Updates the haddock submodule with the minimum changes needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An untyped bracket `HsQuote p` can never be constructed with
`p ~ GhcTc`. This is because we don't typecheck `HsQuote` at all.
That's OK, because we also never use `HsQuote GhcTc`.
To enforce this at the type level we make `HsQuote GhcTc` isomorphic
to `NoExtField` and impossible to construct otherwise, by using TTG field
extensions to make all constructors, except for `XQuote` (which takes `NoExtField`),
unconstructable, with `DataConCantHappen`
This is explained more in detail in Note [The life cycle of a TH quotation]
Related discussion: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4782
|
| |
|
|
|
|
|
|
|
|
|
| |
Split HsBracket into HsTypedBracket and HsUntypedBracket.
Unfortunately, we still cannot get rid of
instance XXTypedBracket GhcTc = HsTypedBracket GhcRn
despite no longer requiring it for typechecking, but rather because the
TH desugarer works on GhcRn rather than GhcTc (See GHC.HsToCore.Quote)
|
| |
|
|
|
|
|
|
|
|
| |
When HsExpr GhcTc, the HsBracket constructor should hold a HsBracket
GhcRn, rather than an HsBracket GhcTc.
We make use of the HsBracket p extension constructor (XBracket
(XXBracket p)) to hold an HsBracket GhcRn when the pass is GhcTc
See !4782 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4782
|
| |
|
|
|
|
|
|
|
|
| |
* Users can define their own (~) type operator
* Haddock can display documentation for the built-in (~)
* New transitional warnings implemented:
-Wtype-equality-out-of-scope
-Wtype-equality-requires-operators
Updates the haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
AbsBinds and ABExport both depended on the typechecker, and were thus
removed from the main AST Expr.
CollectPass now has a new function `collectXXHsBindsLR` used for the new
HsBinds extension point
Bumped haddock submodule to work with AST changes.
The removed Notes from Language.Haskell.Syntax.Binds were duplicated
(and not referenced) and the copies in GHC.Hs.Binds are kept (and
referenced there). (See #19252)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't instantiate type variables for :type in
`GHC.Tc.Gen.App.tcInstFun`, to avoid inconsistently instantianting
`r1` but not `r2` in the type
forall {r1} (a :: TYPE r1) {r2} (b :: TYPE r2). ...
This fixes #21088.
This patch also changes the primop pretty-printer to ensure
that we put all the inferred type variables first. For example,
the type of reallyUnsafePtrEquality# is now
forall {l :: Levity} {k :: Levity}
(a :: TYPE (BoxedRep l))
(b :: TYPE (BoxedRep k)).
a -> b -> Int#
This means we avoid running into issue #21088 entirely with
the types of primops. Users can still write a type signature where
the inferred type variables don't come first, however.
This change to primops had a knock-on consequence, revealing that
we were sometimes performing eta reduction on keepAlive#.
This patch updates tryEtaReduce to avoid eta reducing functions
with no binding, bringing it in line with tryEtaReducePrep,
and thus fixing #21090.
|
| |
|
|
|
|
|
|
|
|
| |
This MR moves the GHC linters into the tree, so that they can be run directly using Hadrian.
* Query all files tracked by Git instead of using changed files, so that we can run the exact same linting step locally and in a merge request.
* Only check that the changelogs don't contain TBA when RELEASE=YES.
* Add hadrian/lint script, which runs all the linting steps.
* Ensure the hlint job exits with a failure if hlint is not installed (otherwise we were ignoring the failure). Given that hlint doesn't seem to be available in CI at the moment, I've temporarily allowed failure in the hlint job.
* Run all linting tests in CI using hadrian.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Co-authored by: Sam Derbyshire
Previously, GHC had three flavours of constraint:
Wanted, Given, and Derived. This removes Derived constraints.
Though serving a number of purposes, the most important role
of Derived constraints was to enable better error messages.
This job has been taken over by the new RewriterSets, as explained
in Note [Wanteds rewrite wanteds] in GHC.Tc.Types.Constraint.
Other knock-on effects:
- Various new Notes as I learned about under-described bits of GHC
- A reshuffling around the AST for implicit-parameter bindings,
with better integration with TTG.
- Various improvements around fundeps. These were caused by the
fact that, previously, fundep constraints were all Derived,
and Derived constraints would get dropped. Thus, an unsolved
Derived didn't stop compilation. Without Derived, this is no
longer possible, and so we have to be considerably more careful
around fundeps.
- A nice little refactoring in GHC.Tc.Errors to center the work
on a new datatype called ErrorItem. Constraints are converted
into ErrorItems at the start of processing, and this allows for
a little preprocessing before the main classification.
- This commit also cleans up the behavior in generalisation around
functional dependencies. Now, if a variable is determined by
functional dependencies, it will not be quantified. This change
is user facing, but it should trim down GHC's strange behavior
around fundeps.
- Previously, reportWanteds did quite a bit of work, even on an empty
WantedConstraints. This commit adds a fast path.
- Now, GHC will unconditionally re-simplify constraints during
quantification. See Note [Unconditionally resimplify constraints when
quantifying], in GHC.Tc.Solver.
Close #18398.
Close #18406.
Solve the fundep-related non-confluence in #18851.
Close #19131.
Close #19137.
Close #20922.
Close #20668.
Close #19665.
-------------------------
Metric Decrease:
LargeRecord
T9872b
T9872b_defer
T9872d
TcPlugin_RewritePerf
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows ghc and its dependencies to be built using a normal
invocation of cabal-install. Each componenent which relied on generated
files or additional configuration now has a Setup.hs file.
There are also various fixes to the cabal files to satisfy
cabal-install.
There is a new hadrian command which will build a stage2 compiler and
then a stage3 compiler by using cabal.
```
./hadrian/build build-cabal
```
There is also a new CI job which tests running this command.
For the 9.4 release we will upload all the dependent executables to
hackage and then end users will be free to build GHC and GHC executables
via cabal.
There are still some unresolved questions about how to ensure soundness
when loading plugins into a reinstalled GHC (#20742) which will be
tighted up in due course.
Fixes #19896
|
| |
|
|
|
|
|
|
|
| |
Adapts GHC to the factoring-out of `Cabal-syntax`.
Fixes #20991.
Metric Decrease:
haddock.Cabal
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Also derive some more instances. GHC doesn't need them, but downstream
consumers may need to e.g. put stuff in maps.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main motivation for this patch is to allow tests to be added to the
testsuite which test things about the source tree without needing to
build GHC. In particular the notes linter can easily start failing and
by integrating it into the testsuite the process of observing these
changes is caught by normal validation procedures rather than having to
run the linter specially.
With this patch I can run
```
./hadrian/build test --flavour=devel2 --only="uniques"
```
In a clean tree to run the checkUniques linter without having to build
GHC.
Fixes #21029
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
directory.
We want to always use the old path (~/.ghc/..) if it exists.
But we never want to create the old path.
This ensures that the migration can eventually be completed once older GHC
versions are no longer in circulation.
Fixes #20684, #20669, #20660
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pretty-printing of partially applied unboxed sums was incorrect,
as we incorrectly dropped the first half of the arguments, even
for a partial application such as
(# | #) @IntRep @DoubleRep Int#
which lead to the nonsensical (# DoubleRep | Int# #).
This patch also allows users to write unboxed sum type constructors
such as
(# | #) :: TYPE r1 -> TYPE r2 -> TYPE (SumRep '[r1,r2]).
Fixes #20858 and #20859.
|
| |
|
|
|
|
| |
SmallArray doesn't perform bounds check (faster).
Make primop tags start at 0 to avoid index arithmetic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple home units allows you to load different packages which may depend on
each other into one GHC session. This will allow both GHCi and HLS to support
multi component projects more naturally.
Public Interface
~~~~~~~~~~~~~~~~
In order to specify multiple units, the -unit @⟨filename⟩ flag
is given multiple times with a response file containing the arguments for each unit.
The response file contains a newline separated list of arguments.
```
ghc -unit @unitLibCore -unit @unitLib
```
where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode.
```
-this-unit-id lib-core-0.1.0.0
-i
-isrc
LibCore.Utils
LibCore.Types
```
The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core.
```
-this-unit-id lib-0.1.0.0
-package-id lib-core-0.1.0.0
-i
-isrc
Lib.Parse
Lib.Render
```
Then when the compiler starts in --make mode it will compile both units lib and lib-core.
There is also very basic support for multiple home units in GHCi, at the
moment you can start a GHCi session with multiple units but only the
:reload is supported. Most commands in GHCi assume a single home unit,
and so it is additional work to work out how to modify the interface to
support multiple loaded home units.
Options used when working with Multiple Home Units
There are a few extra flags which have been introduced specifically for
working with multiple home units. The flags allow a home unit to pretend
it’s more like an installed package, for example, specifying the package
name, module visibility and reexported modules.
-working-dir ⟨dir⟩
It is common to assume that a package is compiled in the directory
where its cabal file resides. Thus, all paths used in the compiler
are assumed to be relative to this directory. When there are
multiple home units the compiler is often not operating in the
standard directory and instead where the cabal.project file is
located. In this case the -working-dir option can be passed which
specifies the path from the current directory to the directory the
unit assumes to be it’s root, normally the directory which contains
the cabal file.
When the flag is passed, any relative paths used by the compiler are
offset by the working directory. Notably this includes -i and
-I⟨dir⟩ flags.
-this-package-name ⟨name⟩
This flag papers over the awkward interaction of the PackageImports
and multiple home units. When using PackageImports you can specify
the name of the package in an import to disambiguate between modules
which appear in multiple packages with the same name.
This flag allows a home unit to be given a package name so that you
can also disambiguate between multiple home units which provide
modules with the same name.
-hidden-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules in a home unit should not be visible outside of the unit it
belongs to.
The main use of this flag is to be able to recreate the difference
between an exposed and hidden module for installed packages.
-reexported-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules are not defined in a unit but should be reexported. The
effect is that other units will see this module as if it was defined
in this unit.
The use of this flag is to be able to replicate the reexported
modules feature of packages with multiple home units.
Offsetting Paths in Template Haskell splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When using Template Haskell to embed files into your program,
traditionally the paths have been interpreted relative to the directory
where the .cabal file resides. This causes problems for multiple home
units as we are compiling many different libraries at once which have
.cabal files in different directories.
For this purpose we have introduced a way to query the value of the
-working-dir flag to the Template Haskell API. By using this function we
can implement a makeRelativeToProject function which offsets a path
which is relative to the original project root by the value of
-working-dir.
```
import Language.Haskell.TH.Syntax ( makeRelativeToProject )
foo = $(makeRelativeToProject "./relative/path" >>= embedFile)
```
> If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units.
A similar function already exists in the file-embed library. The
function in template-haskell implements this function in a more robust
manner by honouring the -working-dir flag rather than searching the file
system.
Closure Property for Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For tools or libraries using the API there is one very important closure
property which must be adhered to:
> Any dependency which is not a home unit must not (transitively) depend
on a home unit.
For example, if you have three packages p, q and r, then if p depends on
q which depends on r then it is illegal to load both p and r as home
units but not q, because q is a dependency of the home unit p which
depends on another home unit r.
If you are using GHC by the command line then this property is checked,
but if you are using the API then you need to check this property
yourself. If you get it wrong you will probably get some very confusing
errors about overlapping instances.
Limitations of Multiple Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a few limitations of the initial implementation which will be smoothed out on user demand.
* Package thinning/renaming syntax is not supported
* More complicated reexports/renaming are not yet supported.
* It’s more common to run into existing linker bugs when loading a
large number of packages in a session (for example #20674, #20689)
* Backpack is not yet supported when using multiple home units.
* Dependency chasing can be quite slow with a large number of
modules and packages.
* Loading wired-in packages as home units is currently not supported
(this only really affects GHC developers attempting to load
template-haskell).
* Barely any normal GHCi features are supported, it would be good to
support enough for ghcid to work correctly.
Despite these limitations, the implementation works already for nearly
all packages. It has been testing on large dependency closures,
including the whole of head.hackage which is a total of 4784 modules
from 452 packages.
Internal Changes
~~~~~~~~~~~~~~~~
* The biggest change is that the HomePackageTable is replaced with the
HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv,
which contains information specific to each home unit.
* The HomeUnitEnv contains:
- A unit state, each home unit can have different package db flags
- A set of dynflags, each home unit can have different flags
- A HomePackageTable
* LinkNode: A new node type is added to the ModuleGraph, this is used to
place the linking step into the build plan so linking can proceed in
parralel with other packages being built.
* New invariant: Dependencies of a ModuleGraphNode can be completely
determined by looking at the value of the node. In order to achieve
this, downsweep now performs a more complete job of downsweeping and
then the dependenices are recorded forever in the node rather than
being computed again from the ModSummary.
* Some transitive module calculations are rewritten to use the
ModuleGraph which is more efficient.
* There is always an active home unit, which simplifies modifying a lot
of the existing API code which is unit agnostic (for example, in the
driver).
The road may be bumpy for a little while after this change but the
basics are well-tested.
One small metric increase, which we accept and also submodule update to
haddock which removes ExtendedModSummary.
Closes #10827
-------------------------
Metric Increase:
MultiLayerModules
-------------------------
Co-authored-by: Fendor <power.walross@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Plugins were directly fetched from HscEnv (hsc_static_plugins and
hsc_plugins). The tight coupling of plugins and of HscEnv is undesirable
and it's better to store them in a new Plugins datatype and to use it in
the plugins' API (e.g. withPlugins, mapPlugins...).
In the process, the interactive context (used by GHCi) got proper
support for different static plugins than those used for loaded modules.
Bump haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This improves some tests that previously failed with:
ghc: panic! (the 'impossible' happened)
GHC version 9.3.20211211:
Failed to lookup LLVM data layout
Target: x86_64-unknown-openbsd
Added the new generated lines to `llvm-targets` on an openbsd
7.0-current with clang 11.1.0.
|
| |
|
|
| |
As proposed in #20546.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in #20794 the parts of libiserv and iserv-proxy depend on
network, therefore are never built nor tested during CI.
Due to this iserv-proxy had bitrotted due to the bound on bytestring
being out of date.
Given we don't test this code it seems undesirable to distribute it.
Therefore, it's removed and an external maintainer can be responsible
for testing it (via head.hackage if desired).
Fixes #20794
|
| |
|
|
|
|
|
|
| |
`check-ppr` features an import of Data.List without an import list.
After 81082cf4, this breaks the local validate flavour because of the compat
warning and `-Werror`. So fix that.
Fixes #20789.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2.
This implements the first step in the plan formulated in #20025 to
improve the communication and migration strategy for the proposed
changes to Data.List.
Requires changing the haddock submodule to update the test output.
|
| |
|
|
|
|
|
| |
Otherwise we end up with issues like #19631 when bootstrapping using GHC
9.2 and above.
Fixes #19631.
|
| |
|
|
|
|
| |
The goal here is to make the SRT selection logic a bit clearer and allow
configurations which we currently don't support (e.g. using a full word
in the info table even when TNTC is used).
|
| |
|
|
|
|
|
|
| |
There were two ways to indicate that a TTG constructor is unused in a phase:
`NoExtCon` and `Void`. This unifies the code, and uses the name
'DataConCantHappen', following the discussion at MR 7041.
Updates haddock submodule
|
