[Git][ghc/ghc][wip/unloading] 14 commits: [skip ci] Fix typo in `callocBytes` haddock.
Ben Gamari
gitlab at gitlab.haskell.org
Sat Oct 31 23:32:01 UTC 2020
Ben Gamari pushed to branch wip/unloading at Glasgow Haskell Compiler / GHC
Commits:
9902d9ec by Viktor Dukhovni at 2020-10-30T05:28:30-04:00
[skip ci] Fix typo in `callocBytes` haddock.
- - - - -
31fcb55f by Ryan Scott at 2020-10-30T18:52:50-04:00
Split HsConDecl{H98,GADT}Details
Haskell98 and GADT constructors both use `HsConDeclDetails`, which includes
`InfixCon`. But `InfixCon` is never used for GADT constructors, which results
in an awkward unrepresentable state. This removes the unrepresentable state by:
* Renaming the existing `HsConDeclDetails` synonym to `HsConDeclH98Details`,
which emphasizes the fact that it is now only used for Haskell98-style data
constructors, and
* Creating a new `HsConDeclGADTDetails` data type with `PrefixConGADT` and
`RecConGADT` constructors that closely resemble `PrefixCon` and `InfixCon`
in `HsConDeclH98Details`. The key difference is that `HsConDeclGADTDetails`
lacks any way to represent infix constructors.
The rest of the patch is refactoring to accommodate the new structure of
`HsConDecl{H98,GADT}Details`. Some highlights:
* The `getConArgs` and `hsConDeclArgTys` functions have been removed, as
there is no way to implement these functions uniformly for all
`ConDecl`s. For the most part, their previous call sites now
pattern match on the `ConDecl`s directly and do different things for
`ConDeclH98`s and `ConDeclGADT`s.
I did introduce one new function to make the transition easier:
`getRecConArgs_maybe`, which extracts the arguments from a `RecCon(GADT)`.
This is still possible since `RecCon(GADT)`s still use the same representation
in both `HsConDeclH98Details` and `HsConDeclGADTDetails`, and since the
pattern that `getRecConArgs_maybe` implements is used in several places,
I thought it worthwhile to factor it out into its own function.
* Previously, the `con_args` fields in `ConDeclH98` and `ConDeclGADT` were
both of type `HsConDeclDetails`. Now, the former is of type
`HsConDeclH98Details`, and the latter is of type `HsConDeclGADTDetails`,
which are distinct types. As a result, I had to rename the `con_args` field
in `ConDeclGADT` to `con_g_args` to make it typecheck.
A consequence of all this is that the `con_args` field is now partial, so
using `con_args` as a top-level field selector is dangerous. (Indeed, Haddock
was using `con_args` at the top-level, which caused it to crash at runtime
before I noticed what was wrong!) I decided to add a disclaimer in the 9.2.1
release notes to advertise this pitfall.
Fixes #18844. Bumps the `haddock` submodule.
- - - - -
57c3db96 by Ryan Scott at 2020-10-31T02:53:55-04:00
Make typechecker equality consider visibility in ForAllTys
Previously, `can_eq_nc'` would equate `ForAllTy`s regardless of their
`ArgFlag`, including `forall i -> i -> Type` and `forall i. i -> Type`! To fix
this, `can_eq_nc'` now uses the `sameVis` function to first check if the
`ArgFlag`s are equal modulo specificity. I have also updated `tcEqType`'s
implementation to match this behavior. For more explanation on the "modulo
specificity" part, see the new `Note [ForAllTy and typechecker equality]`
in `GHC.Tc.Solver.Canonical`.
While I was in town, I fixed some related documentation issues:
* I added `Note [Typechecker equality]` to `GHC.Tc.Utils.TcType` to describe
what exactly distinguishes `can_eq_nc'` and `tcEqType` (which implement
typechecker equality) from `eqType` (which implements definitional equality,
which does not care about the `ArgFlags` of `ForAllTy`s at all).
* The User's Guide had some outdated prose on the specified/inferred
distinction being different for types and kinds, a holdover from #15079. This
is no longer the case on today's GHC, so I removed this prose, added some new
prose to take its place, and added a regression test for the programs in
#15079.
* The User's Guide had some _more_ outdated prose on inferred type variables
not being allowed in `default` type signatures for class methods, which is no
longer true as of the resolution of #18432.
* The related `Note [Deferred Unification]` was being referenced as
`Note [Deferred unification]` elsewhere, which made it harder to `grep`
for. I decided to change the name of the Note to `Deferred unification`
for consistency with the capitalization style used for most other Notes.
Fixes #18863.
- - - - -
a98593f0 by Sylvain Henry at 2020-10-31T02:54:34-04:00
Refactor numeric constant folding rules
Avoid the use of global pattern synonyms.
1) I think it's going to be helpful to implement constant folding for
other numeric types, especially Natural which doesn't have a wrapping
behavior. We'll have to refactor these rules even more so we'd better
make them less cryptic.
2) It should also be slightly faster because global pattern synonyms
matched operations for every numeric types instead of the current one:
e.g., ":**:" pattern was matching multiplication for both Int# and
Word# types. As we will probably want to implement constant folding
for other numeric types (Int8#, Int16#, etc.), it is more efficient
to only match primops for a given type as we do now.
- - - - -
730ef38f by Sylvain Henry at 2020-10-31T02:54:34-04:00
Simplify constant-folding (#18032)
See #18032 for the details.
* Use `Lit (LitNumber _ i)` instead of `isLitValue_maybe` which does
more work but that is not needed for constant-folding
* Don't export `GHC.Types.Literal.isLitValue_maybe`
* Kill `GHC.Types.Literal.isLitValue` which isn't used
- - - - -
d5a53c1a by Ben Gamari at 2020-10-31T02:55:10-04:00
primops.txt.pp: Move ByteArray# primops to separate file
This file will be generated.
- - - - -
b4278a41 by Ben Gamari at 2020-10-31T02:55:10-04:00
primops: Generate ByteArray# index/read/write primops
Previously these were mostly undocumented and was ripe for potential
inconsistencies.
- - - - -
08e6993a by Sylvain Henry at 2020-10-31T02:55:50-04:00
Move loadDecl into IfaceToCore
- - - - -
cb1f755c by Tamar Christina at 2020-10-31T09:26:56-04:00
winio: Fix unused variables warnings
- - - - -
eb368078 by Andrzej Rybczak at 2020-10-31T09:27:34-04:00
Add testcase for #816
- - - - -
baccb8b2 by Ömer Sinan Ağacan at 2020-10-31T19:31:55-04:00
Fix and enable object unloading in GHCi
Fixes #16525 by tracking dependencies between object file symbols and
marking symbol liveness during garbage collection
See Note [Object unloading] in CheckUnload.c for details.
- - - - -
8325c84c by Ray Shih at 2020-10-31T19:31:55-04:00
Add loadNativeObj and unloadNativeObj
(This change is originally written by niteria)
This adds two functions:
* `loadNativeObj`
* `unloadNativeObj`
and implements them for Linux.
They are useful if you want to load a shared object with Haskell code
using the system linker and have GHC call dlclose() after the
code is no longer referenced from the heap.
Using the system linker allows you to load the shared object
above outside the low-mem region. It also loads the DWARF sections
in a way that `perf` understands.
`dl_iterate_phdr` is what makes this implementation Linux specific.
- - - - -
5e1d1056 by GHC GitLab CI at 2020-10-31T19:31:55-04:00
rts: Introduce highMemDynamic
- - - - -
e686c380 by GHC GitLab CI at 2020-10-31T19:31:55-04:00
Introduce test for dynamic library unloading
This uses the highMemDynamic flag introduced earlier to verify that
dynamic objects are properly unloaded.
- - - - -
30 changed files:
- + compiler/GHC/Builtin/bytearray-ops.txt.pp
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Docs.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/IfaceToCore.hs-boot
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Parser/PostProcess/Haddock.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Runtime/Linker.hs
- compiler/GHC/Tc/Solver/Canonical.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/Utils/TcType.hs
- compiler/GHC/Tc/Utils/Unify.hs
- compiler/GHC/ThToHs.hs
- compiler/GHC/Types/Literal.hs
- compiler/GHC/Types/TyThing.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d99dc5bc1715e581fb552f4248b61f5793cd5bda...e686c380d92cf2e57847f4e6d1bc80f38575bf98
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d99dc5bc1715e581fb552f4248b61f5793cd5bda...e686c380d92cf2e57847f4e6d1bc80f38575bf98
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/20201031/3e9e0539/attachment.html>
More information about the ghc-commits
mailing list