[Git][ghc/ghc][wip/T22696] 9 commits: Handle records in the renamer
Ryan Scott (@RyanGlScott)
gitlab at gitlab.haskell.org
Thu Mar 30 11:56:20 UTC 2023
Ryan Scott pushed to branch wip/T22696 at Glasgow Haskell Compiler / GHC
Commits:
3f374399 by sheaf at 2023-03-29T13:57:33+02:00
Handle records in the renamer
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
-------------------------
- - - - -
4f1940f0 by sheaf at 2023-03-29T13:57:33+02:00
Avoid repeatedly shadowing in shadowNames
This commit refactors GHC.Type.Name.Reader.shadowNames to first
accumulate all the shadowing arising from the introduction of a new
set of GREs, and then applies all the shadowing to the old GlobalRdrEnv
in one go.
- - - - -
d246049c by sheaf at 2023-03-29T13:57:34+02:00
igre_prompt_env: discard "only-qualified" names
We were unnecessarily carrying around names only available qualified
in igre_prompt_env, violating the icReaderEnv invariant.
We now get rid of these, as they aren't needed for the shadowing
computation that igre_prompt_env exists for.
Fixes #23177
-------------------------
Metric Decrease:
T14052
T14052Type
-------------------------
- - - - -
41a572f6 by Matthew Pickering at 2023-03-29T16:17:21-04:00
hadrian: Fix path to HpcParser.y
The source for this project has been moved into a src/ folder so we also
need to update this path.
Fixes #23187
- - - - -
b159e0e9 by doyougnu at 2023-03-30T01:40:08-04:00
js: split JMacro into JS eDSL and JS syntax
This commit:
Splits JExpr and JStat into two nearly identical DSLs:
- GHC.JS.Syntax is the JMacro based DSL without unsaturation, i.e., a
value cannot be unsaturated, or, a value of this DSL is a witness that a
value of GHC.JS.Unsat has been saturated
- GHC.JS.Unsat is the JMacro DSL from GHCJS with Unsaturation.
Then all binary and outputable instances are changed to use
GHC.JS.Syntax.
This moves us closer to closing out #22736 and #22352. See #22736 for
roadmap.
-------------------------
Metric Increase:
CoOpt_Read
LargeRecord
ManyAlternatives
PmSeriesS
PmSeriesT
PmSeriesV
T10421
T10858
T11195
T11374
T11822
T12227
T12707
T13035
T13253
T13253-spj
T13379
T14683
T15164
T15703
T16577
T17096
T17516
T17836
T18140
T18282
T18304
T18478
T18698a
T18698b
T18923
T1969
T19695
T20049
T21839c
T3064
T4801
T5321FD
T5321Fun
T5631
T5642
T783
T9198
T9233
T9630
TcPlugin_RewritePerf
WWRec
-------------------------
- - - - -
f4f1f14f by Sylvain Henry at 2023-03-30T01:40:49-04:00
ghc-heap: remove wrong Addr# coercion (#23181)
Conversion from Addr# to I# isn't correct with the JS backend.
Also used the opportunity to reenable 64-bit Word/Int tests
- - - - -
a5360490 by Ben Gamari at 2023-03-30T01:41:25-04:00
testsuite: Fix racing prints in T21465
As noted in #23155, we previously failed to add flushes necessary to
ensure predictable output.
Fixes #23155.
- - - - -
98b5cf67 by Matthew Pickering at 2023-03-30T09:58:40+01:00
Revert "ghc-heap: remove wrong Addr# coercion (#23181)"
This reverts commit f4f1f14f8009c3c120b8b963ec130cbbc774ec02.
This fails to build with GHC-9.2 as a boot compiler.
See #23195 for tracking this issue.
- - - - -
e2b7c4b0 by Ryan Scott at 2023-03-30T07:52:59-04:00
validDerivPred: Reject exotic constraints in IrredPreds
This brings the `IrredPred` case in sync with the treatment of `ClassPred`s as
described in `Note [Valid 'deriving' predicate]` in `GHC.Tc.Validity`. Namely,
we should reject `IrredPred`s that are inferred from `deriving` clauses whose
arguments contain other type constructors, as described in `(VD2) Reject exotic
constraints` of that Note. This has the nice property that `deriving` clauses
whose inferred instance context mention `TypeError` will now emit the type
error in the resulting error message, which better matches existing intuitions
about how `TypeError` should work.
While I was in town, I noticed that much of `Note [Valid 'deriving' predicate]`
was duplicated in a separate `Note [Exotic derived instance contexts]` in
`GHC.Tc.Deriv.Infer`. I decided to fold the latter Note into the former so that
there is a single authority on describing the conditions under which an
inferred `deriving` constraint can be considered valid.
This changes the behavior of `deriving` in a way that existing code might
break, so I have made a mention of this in the GHC User's Guide. It seems very,
very unlikely that much code is relying on this strange behavior, however, and
even if there is, there is a clear, backwards-compatible migration path using
`StandaloneDeriving`.
Fixes #22696.
- - - - -
30 changed files:
- compiler/GHC.hs
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Builtin/Uniques.hs
- compiler/GHC/Builtin/Uniques.hs-boot
- compiler/GHC/Builtin/Utils.hs
- compiler/GHC/ByteCode/Linker.hs
- compiler/GHC/Core/ConLike.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/LateCC.hs
- compiler/GHC/Core/Map/Type.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/TyCon/Env.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Data/FastString/Env.hs
- compiler/GHC/Driver/Env.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/ImpExp.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Errors/Types.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/Iface/Env.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Load.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6ba0aed804d28a19eb10359b8c049b9deadfeb56...e2b7c4b092eb55bfc2443bf5388ead312c39e5f0
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6ba0aed804d28a19eb10359b8c049b9deadfeb56...e2b7c4b092eb55bfc2443bf5388ead312c39e5f0
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/20230330/35acc56e/attachment-0001.html>
More information about the ghc-commits
mailing list