| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit migrates the errors in GHC.Tc.Module to use the new
diagnostic infrastructure.
It required a significant overhaul of the compatibility checks between
an hs-boot or signature module and its implementation; we now use
a Writer monad to accumulate errors; see the BootMismatch datatype
in GHC.Tc.Errors.Types, with its panoply of subtypes.
For the sake of readability, several local functions inside the
'checkBootTyCon' function were split off into top-level functions.
We split off GHC.Types.HscSource into a "boot or sig" vs "normal hs file"
datatype, as this mirrors the logic in several other places where we
want to treat hs-boot and hsig files in a similar fashion.
This commit also refactors the Backpack checks for type synonyms
implementing abstract data, to correctly reject implementations that
contain qualified or quantified types (this fixes #23342 and #23344).
|
|
|
|
|
|
|
|
|
| |
Tracking ticket: #20115
MR: !10350
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
|
|
|
|
|
|
|
|
| |
Commit 3f374399 introduced a bug which caused us to forget to include
the parent of an export item of the form T(..) (that is, IEThingAll)
when checking for duplicate exports.
Fixes #23318
|
|
|
|
|
|
|
|
|
| |
Tracking ticket: #20115
MR: !10336
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When looking up a record field in GHC.Rename.Env.lookupRecFieldOcc,
we could end up calling addUsedGRE on an exact Name, which would then
lead to a panic in the bestImport function: it would be incapable of
processing a GRE which is not local but also not brought into scope
by any imports (as it is referred to by its unique instead).
Fixes #23240
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've turned all occurrences of TcRnUnknownMessage in GHC.Rename.HsType
module into a proper TcRnMessage.
Instead, these TcRnMessage messages were introduced:
TcRnDataKindsError
TcRnUnusedQuantifiedTypeVar
TcRnIllegalKindSignature
TcRnUnexpectedPatSigType
TcRnSectionPrecedenceError
TcRnPrecedenceParsingError
TcRnIllegalKind
TcRnNegativeNumTypeLiteral
TcRnUnexpectedKindVar
TcRnBindMultipleVariables
TcRnBindVarAlreadyInScope
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves the field-based logic for disambiguating record updates
to the renamer. The type-directed logic, scheduled for removal, remains
in the typechecker.
To do this properly (and fix the myriad of bugs surrounding the treatment
of duplicate record fields), we took the following main steps:
1. Create GREInfo, a renamer-level equivalent to TyThing which stores
information pertinent to the renamer.
This allows us to uniformly treat imported and local Names in the
renamer, as described in Note [GREInfo].
2. Remove GreName. Instead of a GlobalRdrElt storing GreNames, which
distinguished between normal names and field names, we now store
simple Names in GlobalRdrElt, along with the new GREInfo information
which allows us to recover the FieldLabel for record fields.
3. Add namespacing for record fields, within the OccNames themselves.
This allows us to remove the mangling of duplicate field selectors.
This change ensures we don't print mangled names to the user in
error messages, and allows us to handle duplicate record fields
in Template Haskell.
4. Move record disambiguation to the renamer, and operate on the
level of data constructors instead, to handle #21443.
The error message text for ambiguous record updates has also been
changed to reflect that type-directed disambiguation is on the way
out.
(3) means that OccEnv is now a bit more complex: we first key on the
textual name, which gives an inner map keyed on NameSpace:
OccEnv a ~ FastStringEnv (UniqFM NameSpace a)
Note that this change, along with (2), both increase the memory residency
of GlobalRdrEnv = OccEnv [GlobalRdrElt], which causes a few tests to
regress somewhat in compile-time allocation.
Even though (3) simplified a lot of code (in particular the treatment of
field selectors within Template Haskell and in error messages), it came
with one important wrinkle: in the situation of
-- M.hs-boot
module M where { data A; foo :: A -> Int }
-- M.hs
module M where { data A = MkA { foo :: Int } }
we have that M.hs-boot exports a variable foo, which is supposed to match
with the record field foo that M exports. To solve this issue, we add a
new impedance-matching binding to M
foo{var} = foo{fld}
This mimics the logic that existed already for impedance-binding DFunIds,
but getting it right was a bit tricky.
See Note [Record field impedance matching] in GHC.Tc.Module.
We also needed to be careful to avoid introducing space leaks in GHCi.
So we dehydrate the GlobalRdrEnv before storing it anywhere, e.g. in
ModIface. This means stubbing out all the GREInfo fields, with the
function forceGlobalRdrEnv.
When we read it back in, we rehydrate with rehydrateGlobalRdrEnv.
This robustly avoids any space leaks caused by retaining old type
environments.
Fixes #13352 #14848 #17381 #17551 #19664 #21443 #21444 #21720 #21898 #21946 #21959 #22125 #22160 #23010 #23062 #23063
Updates haddock submodule
-------------------------
Metric Increase:
MultiComponentModules
MultiLayerModules
MultiLayerModulesDefsGhci
MultiLayerModulesNoCode
T13701
T14697
hard_hole_fits
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #17209. This implements GHC Proposal 541, allowing a WARNING
pragma to be annotated with a category like so:
{-# WARNING in "x-partial" head "This function is undefined on empty lists." #-}
The user can then enable, disable and set the severity of such warnings
using command-line flags `-Wx-partial`, `-Werror=x-partial` and so on. There
is a new warning group `-Wextended-warnings` containing all these warnings.
Warnings without a category are treated as if the category was `deprecations`,
and are (still) controlled by the flags `-Wdeprecations`
and `-Wwarnings-deprecations`.
Updates Haddock submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've turned almost all occurrences of TcRnUnknownMessage in GHC.Rename.Module
module into a proper TcRnMessage.
Instead, these TcRnMessage messages were introduced:
TcRnIllegalInstanceHeadDecl
TcRnUnexpectedStandaloneDerivingDecl
TcRnUnusedVariableInRuleDecl
TcRnUnexpectedStandaloneKindSig
TcRnIllegalRuleLhs
TcRnBadAssocRhs
TcRnDuplicateRoleAnnot
TcRnDuplicateKindSig
TcRnIllegalDerivStrategy
TcRnIllegalMultipleDerivClauses
TcRnNoDerivStratSpecified
TcRnStupidThetaInGadt
TcRnBadImplicitSplice
TcRnShadowedTyVarNameInFamResult
TcRnIncorrectTyVarOnLhsOfInjCond
TcRnUnknownTyVarsOnRhsOfInjCond
Was introduced one helper type:
RuleLhsErrReason
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements GHC proposal 496, which allows record wildcards
to be used for nullary constructors, e.g.
data A = MkA1 | MkA2 { fld1 :: Int }
f :: A -> Int
f (MkA1 {..}) = 0
f (MkA2 {..}) = fld1
To achieve this, we add arity information to the record field
environment, so that we can accept a constructor which has no fields
while continuing to reject non-record constructors with more than 1
field. See Note [Nullary constructors and empty record wildcards],
as well as the more general overview in Note [Local constructor info in the renamer],
both in the newly introduced GHC.Types.ConInfo module.
Fixes #22161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Type variables from class/instance headers scope over class/instance
method type signatures, but DO NOT scope over the type signatures in
SPECIALISE and SPECIALISE instance pragmas.
The logic in GHC.Rename.Bind.rnMethodBinds correctly accounted for
SPECIALISE inline pragmas, but forgot to apply the same treatment
to method SPECIALISE pragmas, which lead to a Core Lint failure with
an out-of-scope type variable. This patch makes sure we apply the same
logic for both cases.
Fixes #22913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR runs the testsuite for the JS backend. Note that this is a
temporary solution until !9515 is merged.
Key point: The CI runs hadrian on the built cross compiler _but not_ on
the bindist.
Other Highlights:
- stm submodule gets a bump to mark tests as broken
- several tests are marked as broken or are fixed by adding more
- conditions to their test runner instance.
List of working commit messages:
CI: test cross target _and_ emulator
CI: JS: Try run testsuite with hadrian
JS.CI: cleanup and simplify hadrian invocation
use single bracket, print info
JS CI: remove call to test_compiler from hadrian
don't build haddock
JS: mark more tests as broken
Tracked in https://gitlab.haskell.org/ghc/ghc/-/issues/22576
JS testsuite: don't skip sum_mod test
Its expected to fail, yet we skipped it which automatically makes it
succeed leading to an unexpected success,
JS testsuite: don't mark T12035j as skip
leads to an unexpected pass
JS testsuite: remove broken on T14075
leads to unexpected pass
JS testsuite: mark more tests as broken
JS testsuite: mark T11760 in base as broken
JS testsuite: mark ManyUnbSums broken
submodules: bump process and hpc for JS tests
Both submodules has needed tests skipped or marked broken for th JS
backend. This commit now adds these changes to GHC.
See:
HPC: https://gitlab.haskell.org/hpc/hpc/-/merge_requests/21
Process: https://github.com/haskell/process/pull/268
remove js_broken on now passing tests
separate wasm and js backend ci
test: T11760: add threaded, non-moving only_ways
test: T10296a add req_c
T13894: skip for JS backend
tests: jspace, T22333: mark as js_broken(22573)
test: T22513i mark as req_th
stm submodule: mark stm055, T16707 broken for JS
tests: js_broken(22374) on unpack_sums_6, T12010
dont run diff on JS CI, cleanup
fixup: More CI cleanup
fix: align text to master
fix: align exceptions submodule to master
CI: Bump DOCKER_REV
Bump to ci-images commit that has a deb11 build with node. Required for
!9552
testsuite: mark T22669 as js_skip
See #22669
This test tests that .o-boot files aren't created when run in using the
interpreter backend. Thus this is not relevant for the JS backend.
testsuite: mark T22671 as broken on JS
See #22835
base.testsuite: mark Chan002 fragile for JS
see #22836
revert: submodule process bump
bump stm submodule
New hash includes skips for the JS backend.
testsuite: mark RnPatternSynonymFail broken on JS
Requires TH:
- see !9779
- and #22261
compiler: GHC.hs ifdef import Utils.Panic.Plain
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I removed all occurrences of TcRnUnknownMessage in GHC.Rename.Bind
module. Instead, these TcRnMessage messages were introduced:
TcRnMultipleFixityDecls
TcRnIllegalPatternSynonymDecl
TcRnIllegalClassBiding
TcRnOrphanCompletePragma
TcRnEmptyCase
TcRnNonStdGuards
TcRnDuplicateSigDecl
TcRnMisplacedSigDecl
TcRnUnexpectedDefaultSig
TcRnBindInBootFile
TcRnDuplicateMinimalSig
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new warning
that indicates code incompatible with
future extension: RequiredTypeArguments.
Enabling this extension may break some code and the warning
will help to make it compatible in advance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #20472 it was pointed out that you couldn't defer out of scope but
the implementation collapsed a RdrName into an OccName to stuff it into
a Hole. This leads to the error message for a deferred qualified name
dropping the qualification which affects the quality of the error
message.
This commit adds a bit more structure to a hole, so a hole can replace a
RdrName without losing information about what that RdrName was. This is
important when printing error messages.
I also added a test which checks the Template Haskell deferral of out of
scope qualified names works properly.
Fixes #22130
|
|
|
|
|
| |
Necessary for newer cross-compiling backends (JS, Wasm) that don't
support TH yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the examples in #22057 which show we have to traverse deeply into a
pattern to determine whether it contains a splice or not. The original
implementation pointed this out but deemed this very shallow traversal
"too expensive".
Fixes #22057
I also fixed an oversight in !7821 which meant we lost a warning which
was present in 9.2.2.
Fixes #22067
|
|
|
|
|
|
|
|
| |
The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was some confusion about whether FUN/TYPE/One/Many should be
BuiltInSyntax or UserSyntax. The answer is certainly UserSyntax as
BuiltInSyntax is for things which are directly constructed by the parser
rather than going through normal renaming channels.
I fixed all the obviously wrong places I could find and added a test for
the original bug which was caused by this (#21752)
Fixes #21752 #20695 #18302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes #20312
It deprecates "TypeInType" extension
according to the following proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0083-no-type-in-type.rst
It has been already implemented.
The migration strategy:
1. Disable TypeInType
2. Enable both DataKinds and PolyKinds extensions
Metric Decrease:
T16875
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit acb188e0 introduced a regression in the computation of free
variables in mdo statements, as the logic in
GHC.Rename.Expr.segmentRecStmts was slightly different depending on
whether the recursive do block corresponded to an mdo statement or
a rec statment.
This patch restores the previous computation for mdo blocks.
Fixes #21654
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
|
|
| |
Update manual; explain ticks as optional disambiguation
rather than the preferred default.
This is a part of #20531.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
In accordance with GHC Proposal #281 "Visible forall in types of terms":
For three releases before this change takes place, include a new
warning -Wforall-identifier in -Wdefault. This warning will be triggered
at definition sites (but not use sites) of forall as an identifier.
Updates the haddock submodule.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit converts a bunch of HsToCore (Ds) messages to use the new
GHC's diagnostic message infrastructure. In particular the DsMessage
type has been expanded with a lot of type constructors, each
encapsulating a particular error and warning emitted during desugaring.
Due to the fact that levity polymorphism checking can happen both at the
Ds and at the TcRn level, a new `TcLevityCheckDsMessage` constructor has
been added to the `TcRnMessage` type.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Change the names of the fields in in `data FieldOcc`
- Renames `HsRecFld` to `HsRecSel`
- Replace `AmbiguousFieldOcc p` in `HsRecSel` with `FieldOcc p`
- Contains a haddock submodule update
The primary motivation of this change is to remove
`AmbiguousFieldOcc`. This is one of a suite of changes improving how
record syntax (most notably record update syntax) is represented in
the AST.
|
|
|
|
|
|
|
| |
- Remove GHC.OldList
- Remove Data.OldList
- compat-unqualified-imports is no-op
- update haddock submodule
|
| |
|
|
|
|
|
|
| |
Fixes #18966. Adds a new warning -Wambiguous-fields for uses of field selectors
or record updates that will be rejected in the future, when the DuplicateRecordFields
extension is simplified per https://github.com/ghc-proposals/ghc-proposals/pull/366.
|
|
|
|
|
| |
Fixes #17853. We mustn't discard the result of pickGREs, because doing
so might lead to incorrect redundant import warnings.
|
|
|
|
|
|
|
|
| |
This commit fixes 19 tests which were failing due to the use of
`consBag` / `snocBag`, which have been now replaced by `addMessage`.
This means that now GHC would output things in different order but
only for /diagnostics on the same line/, so this is just reflecting
that. The "normal" order of messages is still guaranteed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
source syntax (#18565)
Previously, we desugared and coverage checked plain guard trees as
described in Lower Your Guards. That caused (in !3849) quite a bit of
pain when we need to partially recover tree structure of the input
syntax to return covered sets for long-distance information, for
example.
In this refactor, I introduced a guard tree variant for each relevant
source syntax component of a pattern-match (mainly match groups, match,
GRHS, empty case, pattern binding). I made sure to share as much
coverage checking code as possible, so that the syntax-specific checking
functions are just wrappers around the more substantial checking
functions for the LYG primitives (`checkSequence`, `checkGrds`).
The refactoring payed off in clearer code and elimination of all panics
related to assumed guard tree structure and thus fixes #18565.
I also took the liberty to rename and re-arrange the order of functions
and comments in the module, deleted some dead and irrelevant Notes,
wrote some new ones and gave an overview module haddock.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* support detection of slow ghc-bignum backend (to replace the detection
of integer-simple use). There are still some test cases that the
native backend doesn't handle efficiently enough.
* remove tests for GMP only functions that have been removed from
ghc-bignum
* fix test results showing dependent packages (e.g. integer-gmp) or
showing suggested instances
* fix test using Integer/Natural API or showing internal names
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both `bindLHsTyVarBndrs` and `bindHsQTyVars` take two separate
`Maybe` arguments, which I find terribly confusing. Thankfully, it's
possible to remove one `Maybe` argument from each of these functions,
which this patch accomplishes:
* `bindHsQTyVars` takes a `Maybe SDoc` argument, which is `Just` if
GHC should warn about any of the quantified type variables going
unused. However, every call site uses `Nothing` in practice. This
makes sense, since it doesn't really make sense to warn about
unused type variables bound by an `LHsQTyVars`. For instance, you
wouldn't warn about the `a` in `data Proxy a = Proxy` going unused.
As a result, I simply remove this `Maybe SDoc` argument altogether.
* `bindLHsTyVarBndrs` also takes a `Maybe SDoc` argument for the same
reasons that `bindHsQTyVars` took one. To make things more
confusing, however, `bindLHsTyVarBndrs` also takes a separate
`HsDocContext` argument, which is pretty-printed (to an `SDoc`) in
warnings and error messages.
In practice, the `Maybe SDoc` and the `HsDocContext` often contain
the same text. See the call sites for `bindLHsTyVarBndrs` in
`rnFamInstEqn` and `rnConDecl`, for instance. There are only a
handful of call sites where the text differs between the
`Maybe SDoc` and `HsDocContext` arguments:
* In `rnHsRuleDecl`, where the `Maybe SDoc` says "`In the rule`"
and the `HsDocContext` says "`In the transformation rule`".
* In `rnHsTyKi`/`rn_ty`, where the `Maybe SDoc` says
"`In the type`" but the `HsDocContext` is inhereted from the
surrounding context (e.g., if `rnHsTyKi` were called on a
top-level type signature, the `HsDocContext` would be
"`In the type signature`" instead)
In both cases, warnings/error messages arguably _improve_ by
unifying making the `Maybe SDoc`'s text match that of the
`HsDocContext`. As a result, I decided to remove the `Maybe SDoc`
argument to `bindLHsTyVarBndrs` entirely and simply reuse the text
from the `HsDocContext`. (I decided to change the phrase
"transformation rule" to "rewrite rule" while I was in the area.)
The `Maybe SDoc` argument has one other purpose: signaling when to
emit "`Unused quantified type variable`" warnings. To recover this
functionality, I replaced the `Maybe SDoc` argument with a
boolean-like `WarnUnusedForalls` argument. The only
`bindLHsTyVarBndrs` call site that chooses _not_ to emit these
warnings in `bindHsQTyVars`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, `tcRules` would check for naughty quantification
candidates (see `Note [Naughty quantification candidates]` in
`TcMType`) when generalising over the type of a rewrite rule. This
caused sensible-looking rewrite rules (like those in #17710) to be
rejected. A more permissing (and easier-to-implement) approach is to
do what is described in `Note [Generalising in tcTyFamInstEqnGuts]`
in `TcTyClsDecls`: just re-quantify all the type variable binders,
regardless of the order in which the user specified them. After all,
the notion of type variable specificity has no real meaning in
rewrite rules, since one cannot "visibly apply" a rewrite rule.
I have written up this wisdom in
`Note [Re-quantify type variables in rules]` in `TcRules`.
As a result of this patch, compiling the `ExplicitForAllRules1` test
case now generates one fewer warning than it used to. As far as I can
tell, this is benign, since the thing that the disappearing warning
talked about was also mentioned in an entirely separate warning.
Fixes #17710.
|
|
|
|
|
|
|
| |
Switching from `lookupGlobalOccRn_maybe` to `lookupInfoOccRn`
to check whether a `main` function is in scope. Unfortunately
`lookupGlobalOccRn_maybe` complains if there are multiple `main`
functions in scope.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the warning proposed in option (B) of the
Data.List.singleton CLC [discussion][].
This warning, which is included in `-Wcompat` is intended to help users
identify imports of modules that will change incompatibly in future GHC
releases. This currently only includes `Data.List` due to the expected
specialisation and addition of `Data.List.singleton`.
Fixes #17244.
[discussion]: https://groups.google.com/d/msg/haskell-core-libraries/q3zHLmzBa5E/PmlAs_kYAQAJ
|