[Git][ghc/ghc][wip/T23153] 39 commits: Allow WARNING pragmas to be controlled with custom categories
sheaf (@sheaf)
gitlab at gitlab.haskell.org
Fri Mar 31 13:03:19 UTC 2023
sheaf pushed to branch wip/T23153 at Glasgow Haskell Compiler / GHC
Commits:
f932c589 by Adam Gundry at 2023-03-24T02:36:09-04:00
Allow WARNING pragmas to be controlled with custom categories
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.
- - - - -
0426515b by Adam Gundry at 2023-03-24T02:36:09-04:00
Move mention of warning groups change to 9.8.1 release notes
- - - - -
b8d783d2 by Ben Gamari at 2023-03-24T02:36:45-04:00
nativeGen/AArch64: Fix bitmask immediate predicate
Previously the predicate for determining whether a logical instruction
operand could be encoded as a bitmask immediate was far too
conservative. This meant that, e.g., pointer untagged required five
instructions whereas it should only require one.
Fixes #23030.
- - - - -
46120bb6 by Joachim Breitner at 2023-03-24T13:09:43-04:00
User's guide: Improve docs for -Wall
previously it would list the warnings _not_ enabled by -Wall. That’s
unnecessary round-about and was out of date. So let's just name
the relevant warnings (based on `compiler/GHC/Driver/Flags.hs`).
- - - - -
509d1f11 by Ben Gamari at 2023-03-24T13:10:20-04:00
codeGen/tsan: Disable instrumentation of unaligned stores
There is some disagreement regarding the prototype of
`__tsan_unaligned_write` (specifically whether it takes just the written
address, or the address and the value as an argument). Moreover, I have
observed crashes which appear to be due to it. Disable instrumentation
of unaligned stores as a temporary mitigation.
Fixes #23096.
- - - - -
6a73655f by Li-yao Xia at 2023-03-25T00:02:44-04:00
base: Document GHC versions associated with past base versions in the changelog
- - - - -
43bd7694 by Teo Camarasu at 2023-03-25T00:03:24-04:00
Add regression test for #17574
This test currently fails in the nonmoving way
- - - - -
f2d56bf7 by Teo Camarasu at 2023-03-25T00:03:24-04:00
fix: account for large and compact object stats with nonmoving gc
Make sure that we keep track of the size of large and compact objects that have been moved onto the nonmoving heap.
We keep track of their size and add it to the amount of live bytes in nonmoving segments to get the total size of the live nonmoving heap.
Resolves #17574
- - - - -
7131b705 by David Feuer at 2023-03-25T00:04:04-04:00
Modify ThreadId documentation and comments
For a long time, `GHC.Conc.Sync` has said
```haskell
-- ToDo: data ThreadId = ThreadId (Weak ThreadId#)
-- But since ThreadId# is unlifted, the Weak type must use open
-- type variables.
```
We are now actually capable of using `Weak# ThreadId#`, but the
world has moved on. To support the `Show` and `Ord` instances, we'd
need to store the thread ID number in the `ThreadId`. And it seems
very difficult to continue to support `threadStatus` in that regime,
since it needs to be able to explain how threads died. In addition,
garbage collection of weak references can be quite expensive, and it
would be hard to evaluate the cost over he whole ecosystem. As discussed
in
[this CLC issue](https://github.com/haskell/core-libraries-committee/issues/125),
it doesn't seem very likely that we'll actually switch to weak
references here.
- - - - -
c421bbbb by Ben Gamari at 2023-03-25T00:04:41-04:00
rts: Fix barriers of IND and IND_STATIC
Previously IND and IND_STATIC lacked the acquire barriers enjoyed by
BLACKHOLE. As noted in the (now updated) Note [Heap memory barriers],
this barrier is critical to ensure that the indirectee is visible to the
entering core.
Fixes #22872.
- - - - -
62fa7faa by Bodigrim at 2023-03-25T00:05:22-04:00
Improve documentation of atomicModifyMutVar2#
- - - - -
b2d14d0b by Cheng Shao at 2023-03-25T03:46:43-04:00
rts: use performBlockingMajorGC in hs_perform_gc and fix ffi023
This patch does a few things:
- Add the missing RtsSymbols.c entry of performBlockingMajorGC
- Make hs_perform_gc call performBlockingMajorGC, which restores
previous behavior
- Use hs_perform_gc in ffi023
- Remove rts_clearMemory() call in ffi023, it now works again in some
test ways previously marked as broken. Fixes #23089
- - - - -
d9ae24ad by Cheng Shao at 2023-03-25T03:46:44-04:00
testsuite: add the rts_clearMemory test case
This patch adds a standalone test case for rts_clearMemory that mimics
how it's typically used by wasm backend users and ensures this RTS API
isn't broken by future RTS refactorings. Fixes #23901.
- - - - -
80729d96 by Bodigrim at 2023-03-25T03:47:22-04:00
Improve documentation for resizing of byte arrays
- - - - -
c6ec4cd1 by Ben Gamari at 2023-03-25T20:23:47-04:00
rts: Don't rely on EXTERN_INLINE for slop-zeroing logic
Previously we relied on calling EXTERN_INLINE functions defined in
ClosureMacros.h from Cmm to zero slop. However, as far as I can tell,
this is no longer safe to do in C99 as EXTERN_INLINE definitions may be emitted
in each compilation unit.
Fix this by explicitly declaring a new set of non-inline functions in
ZeroSlop.c which can be called from Cmm and marking the ClosureMacros.h
definitions as INLINE_HEADER.
In the future we should try to eliminate EXTERN_INLINE.
- - - - -
c32abd4b by Ben Gamari at 2023-03-25T20:23:48-04:00
rts: Fix capability-count check in zeroSlop
Previously `zeroSlop` examined `RtsFlags` to determine whether the
program was single-threaded. This is wrong; a program may be started
with `+RTS -N1` yet the process may later increase the capability count
with `setNumCapabilities`. This lead to quite subtle and rare crashes.
Fixes #23088.
- - - - -
656d4cb3 by Ryan Scott at 2023-03-25T20:24:23-04:00
Add Eq/Ord instances for SSymbol, SChar, and SNat
This implements [CLC proposal #148](https://github.com/haskell/core-libraries-committee/issues/148).
- - - - -
4f93de88 by David Feuer at 2023-03-26T15:33:02-04:00
Update and expand atomic modification Haddocks
* The documentation for `atomicModifyIORef` and `atomicModifyIORef'`
were incomplete, and the documentation for `atomicModifyIORef` was
out of date. Update and expand.
* Remove a useless lazy pattern match in the definition of
`atomicModifyIORef`. The pair it claims to match lazily
was already forced by `atomicModifyIORef2`.
- - - - -
e1fb56b2 by David Feuer at 2023-03-26T15:33:41-04:00
Document the constructor name for lists
Derived `Data` instances use raw infix constructor names when applicable.
The `Data.Data [a]` instance, if derived, would have a constructor name
of `":"`. However, it actually uses constructor name `"(:)"`. Document this
peculiarity.
See https://github.com/haskell/core-libraries-committee/issues/147
- - - - -
c1f755c4 by Simon Peyton Jones at 2023-03-27T22:09:41+01:00
Make exprIsConApp_maybe a bit cleverer
Addresses #23159.
See Note Note [Exploit occ-info in exprIsConApp_maybe]
in GHC.Core.SimpleOpt.
Compile times go down very slightly, but always go down,
never up. Good!
Metrics: compile_time/bytes allocated
------------------------------------------------
CoOpt_Singletons(normal) -1.8%
T15703(normal) -1.2% GOOD
geo. mean -0.1%
minimum -1.8%
maximum +0.0%
Metric Decrease:
CoOpt_Singletons
T15703
- - - - -
76bb4c58 by Ryan Scott at 2023-03-28T08:12:08-04:00
Add COMPLETE pragmas to TypeRep, SSymbol, SChar, and SNat
This implements
[CLC proposal #149](https://github.com/haskell/core-libraries-committee/issues/149).
- - - - -
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.
- - - - -
61a2dfaa by Bodigrim at 2023-03-30T14:35:57-04:00
Add {-# WARNING #-} to Data.List.{head,tail}
- - - - -
8f15c47c by Bodigrim at 2023-03-30T14:35:57-04:00
Fixes to accomodate Data.List.{head,tail} with {-# WARNING #-}
- - - - -
7c7dbade by Bodigrim at 2023-03-30T14:35:57-04:00
Bump submodules
- - - - -
d2d8251b by Bodigrim at 2023-03-30T14:35:57-04:00
Fix tests
- - - - -
3d38dcb6 by sheaf at 2023-03-30T14:35:57-04:00
Proxies for head and tail: review suggestions
- - - - -
930edcfd by sheaf at 2023-03-30T14:36:33-04:00
docs: move RecordUpd changelog entry to 9.8
This was accidentally included in the 9.6 changelog
instead of the 9.6 changelog.
- - - - -
6f885e65 by sheaf at 2023-03-30T14:37:09-04:00
Add LANGUAGE GADTs to GHC.Rename.Env
We need to enable this extension for the file to compile with ghc 9.2,
as we are pattern matching on a GADT and this required the GADT extension
to be enabled until 9.4.
- - - - -
2e865058 by Simon Peyton Jones at 2023-03-31T11:22:06+01:00
Major refactor in the handling of equality constraints
This MR substantially refactors the way in which the constraint
solver deals with equality constraints. The big thing is:
* Intead of a pipeline in which we /first/ canonicalise and /then/
interact (the latter including performing unification) the two steps
are more closely integreated into one. That avoids the current
rather indirect communication between the two steps.
The proximate cause for this refactoring is fixing #22194, which involve
solving [W] alpha[2] ~ Maybe (F beta[4])
by doing this:
alpha[2] := Maybe delta[2]
[W] delta[2] ~ F beta[4]
That is, we don't promote beta[4]! This is very like introducing a cycle
breaker, and was very awkward to do before, but now it is all nice.
See GHC.Tc.Utils.Unify Note [Promotion and level-checking] and
Note [Family applications in canonical constraints].
The big change is this:
* Several canonicalisation checks (occurs-check, cycle-breaking,
checking for concreteness) are combined into one new function:
GHC.Tc.Utils.Unify.checkTyEqRhs
This function is controlled by `TyEqFlags`, which says what to do
for foralls, type families etc.
* `canEqCanLHSFinish` now sees if unification is possible, and if so,
actually does it: see `canEqCanLHSFinish_try_unification`.
There are loads of smaller changes:
* The on-the-fly unifier `GHC.Tc.Utils.Unify.unifyType` has a
cheap-and-cheerful version of `checkTyEqRhs`, called
`simpleUnifyCheck`. If `simpleUnifyCheck` succeeds, it can unify,
otherwise it defers by emitting a constraint. This is simpler than
before.
* I simplified the swapping code in `GHC.Tc.Solver.Equality.canEqCanLHS`.
Especially the nasty stuff involving `swap_for_occurs` and
`canEqTyVarFunEq`. Much nicer now. See
Note [Orienting TyVarLHS/TyFamLHS]
Note [Orienting TyFamLHS/TyFamLHS]
* Added `cteSkolemOccurs`, `cteConcrete`, and `cteCoercionHole` to the
problems that can be discovered by `checkTyEqRhs`.
* I fixed #23199 `pickQuantifiablePreds`, which actually allows GHC to
to accept both cases in #22194 rather than rejecting both.
Yet smaller:
* Added a `synIsConcrete` flag to `SynonymTyCon` (alongside `synIsFamFree`)
to reduce the need for synonym expansion when checking concreteness.
Use it in `isConcreteType`.
* Renamed `isConcrete` to `isConcreteType`
* Defined `GHC.Core.TyCo.FVs.isInjectiveInType` as a more efficient
way to find if a particular type variable is used injectively than
finding all the injective variables. It is called in
`GHC.Tc.Utils.Unify.definitely_poly`, which in turn is used quite a
lot.
* Moved `rewriterView` to `GHC.Core.Type`, so we can use it from the
constraint solver.
Fixes #22194, #23199
Compile times decrease by an average of 0.1%; but there is a 7.4%
drop in compiler allocation on T15703.
Metric Decrease:
T15703
- - - - -
7a3fb210 by Krzysztof Gogolewski at 2023-03-31T13:30:25+02:00
Show an error when we cannot default a concrete tyvar
Fixes #23153
- - - - -
6e8aab88 by sheaf at 2023-03-31T15:03:11+02:00
Handle ConcreteTvs in inferResultToType
inferResultToType was discarding the ir_frr information, which meant
some metavariables ended up being MetaTvs instead of ConcreteTvs.
This function now creates new ConcreteTvs as necessary, instead of
always creating MetaTvs.
Fixes #23154
- - - - -
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/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Linker.hs
- compiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.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/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/TyCon/Env.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Type.hs-boot
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Data/Bag.hs
- compiler/GHC/Data/FastString/Env.hs
- compiler/GHC/Data/Maybe.hs
- compiler/GHC/Driver/Config/Diagnostic.hs
- compiler/GHC/Driver/Env.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Session.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9ab9b30ec1affe22b188f9a6637ac3bdea75bdba...6e8aab88084d63b81995430a88b787f8748f56a0
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9ab9b30ec1affe22b188f9a6637ac3bdea75bdba...6e8aab88084d63b81995430a88b787f8748f56a0
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/20230331/5ef8129d/attachment-0001.html>
More information about the ghc-commits
mailing list