[Git][ghc/ghc][wip/T25281] 12 commits: Deprecation for WarnCompatUnqualifiedImports
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Mon Oct 7 09:18:02 UTC 2024
Simon Peyton Jones pushed to branch wip/T25281 at Glasgow Haskell Compiler / GHC
Commits:
68e2da5a by Rodrigo Mesquita at 2024-10-05T10:36:15-04:00
Deprecation for WarnCompatUnqualifiedImports
Fixes #25330
- - - - -
4327f0e8 by Andrew Lelechenko at 2024-10-05T10:36:52-04:00
Restrict Data.List.NonEmpty.unzip to NonEmpty (a, b) -> (NonEmpty a, NonEmpty b)
Implementing the final phase of CLC proposal https://github.com/haskell/core-libraries-committee/issues/86
- - - - -
ceca9efb by Cheng Shao at 2024-10-06T02:18:31+00:00
driver: fix runWorkerLimit on wasm
This commit fixes link-time unresolved symbol errors for sem_open etc
on wasm, by making runWorkerLimit always behave single-threaded. This
avoids introducing the jobserver logic into the final wasm module and
thus avoids referencing the posix semaphore symbols.
- - - - -
135fd1ac by Torsten Schmits at 2024-10-06T02:18:31+00:00
Parallelize getRootSummary computations in dep analysis downsweep
This reuses the upsweep step's infrastructure to process batches of
modules in parallel.
I benchmarked this by running `ghc -M` on two sets of 10,000 modules;
one with a linear dependency chain and the other with a binary tree.
Comparing different values for the number of modules per thread
suggested an optimum at `length targets `div` (n_cap * 2)`, with results
similar to this one (6 cores, 12 threads):
```
Benchmark 1: linear 1 jobs
Time (mean ± σ): 1.775 s ± 0.026 s [User: 1.377 s, System: 0.399 s]
Range (min … max): 1.757 s … 1.793 s 2 runs
Benchmark 2: linear 6 jobs
Time (mean ± σ): 876.2 ms ± 20.9 ms [User: 1833.2 ms, System: 518.6 ms]
Range (min … max): 856.2 ms … 898.0 ms 3 runs
Benchmark 3: linear 12 jobs
Time (mean ± σ): 793.5 ms ± 23.2 ms [User: 2318.9 ms, System: 718.6 ms]
Range (min … max): 771.9 ms … 818.0 ms 3 runs
```
Results don't differ much when the batch size is reduced to a quarter
of that, but there's significant thread scheduling overhead for a size
of 1:
```
Benchmark 1: linear 1 jobs
Time (mean ± σ): 2.611 s ± 0.029 s [User: 2.851 s, System: 0.783 s]
Range (min … max): 2.591 s … 2.632 s 2 runs
Benchmark 2: linear 6 jobs
Time (mean ± σ): 1.189 s ± 0.007 s [User: 2.707 s, System: 1.103 s]
Range (min … max): 1.184 s … 1.194 s 2 runs
Benchmark 3: linear 12 jobs
Time (mean ± σ): 1.097 s ± 0.006 s [User: 2.938 s, System: 1.300 s]
Range (min … max): 1.093 s … 1.101 s 2 runs
```
Larger batches also slightly worsen performance.
- - - - -
535a2117 by Daniel Díaz at 2024-10-06T09:51:46-04:00
Clarify the meaning of "exactly once" in LinearTypes
Solves documentaion issue #25084.
- - - - -
92f8939a by Krzysztof Gogolewski at 2024-10-06T09:52:22-04:00
Only allow (a => b) :: Constraint rather than CONSTRAINT rep
Fixes #25243
- - - - -
19bd6a1f by Sebastian Graf at 2024-10-07T08:34:07+01:00
Desugaring, plus -Wincomplete-record-selectors
This commit does several related things:
* Major refactor of the handling of applications in the desugarer.
Now all applications are handled in `dsApp`, `ds_app` and related
functions. This dramatically simplifies the code and removes
complicated cruft that had accumulated. Hooray.
Fixes #25281.
* Improve the handling of -Wincomplete-record-selectors.
We now incorporate the result type of unsaturated record selector
applications as well as consider long-distance information in
getField applications.
Plus, the implmentation now builds the improved `dsApp` stuff
above, so it is much easier to understand.
Plus, incorporates improved error message wording suggested
by Adam Gundry in !12685.
Fixes #24824, #24891
See the long Note [Detecting incomplete record selectors]
* Add -Wincomplete-record-selectors to -Wall, as specified in
GHC Proposal 516.
To do this, I also had to add -Wno-incomplete-record-selectors
to the build flags for Cabal in GHC's CI. See
hadrian/src/Settings/Warnings.hs. We can remove this when
Cabal is updated so that it doesn't trigger the warning:
https://github.com/haskell/cabal/issues/10402
2.6% decrease in compile time allocation in RecordUpPerf
Metric Decrease:
RecordUpdPerf
- - - - -
5b5b6cc2 by Simon Peyton Jones at 2024-10-07T08:34:07+01:00
Elmininate incomplete record selectors
This patch is a pure refactor of GHC's source code, to avoid the use
of partial record selectors. It was provoked by adding
-Wincomplete-record-selectors to -Wall (as the GHC Proposal specified),
which in turn showed up lots of places where GHC was using incomplete
record selectors.
This patch does mostly-simple refactoring to make it clear to the pattern
match checker that there is in fact no partiality.
There is one externally-visible change: I changed the data type HoleFit
to split out the two cases
data HoleFit = TcHoleFit TcHoleFit | RawHoleFit SDoc
data TcHoleFit = HoleFit { ...lots of fields }
There are large swathes of code that just deal with `TcHoleFit`, and
having it as a separate data types makes it apparent that `RawHoleFit`
can't occur.
This makes it much better -- but the change is visible in the
HolePlugin interface. I decided that there are so few clients of this
API that it's worth the change.
I moved several functions from Language.Haskell.Syntax to GHC.Hs.
Reason, when instantiated at (GhcPass _), the extension data construtcor
is guaranteed unused, and that justifies omitted patterns in these
functions. By putting them in GHC.Hs.X I can specialise the type for
(GhcPass _) and thereby make the function total.
An interesting side-light is that there were a few local function
definitions without a type signature, like this one in GHC.Parser.Header
convImport (L _ i) = (ideclPkgQual i, reLoc $ ideclName i)
This is fully closed, and so is generalised; but that generalises
it to any old pass, not (GhcPass _), so GHC rightly complains about the
use of the selector `ideclPkgQual`. I added a type signature to `i`, thus
convImport (L _ (i::ImportDecl GhcPs))
= (ideclPkgQual i, reLoc $ ideclName i)
which specialised the function enough to make the record selector complete.
Quite a surprising consequence of local let-generalisation!
- - - - -
4e69c01e by Simon Peyton Jones at 2024-10-07T08:34:07+01:00
Yet more
- - - - -
0614c061 by Simon Peyton Jones at 2024-10-07T08:34:07+01:00
One more
- - - - -
cabe5e38 by Simon Peyton Jones at 2024-10-07T08:34:07+01:00
More
- - - - -
c43bf0aa by Simon Peyton Jones at 2024-10-07T10:17:40+01:00
More
- - - - -
30 changed files:
- compiler/GHC/CmmToAsm/Dwarf/Types.hs
- compiler/GHC/CmmToAsm/Reg/Graph/Stats.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/ConLike.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/LateCC/OverloadedCalls.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Stats.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/90e4736b624a9eb9485fce56e027e59d5e6f8d6c...c43bf0aaed81c6a9b5d370f5ae7ddde86fe644ae
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/90e4736b624a9eb9485fce56e027e59d5e6f8d6c...c43bf0aaed81c6a9b5d370f5ae7ddde86fe644ae
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/20241007/c1754811/attachment-0001.html>
More information about the ghc-commits
mailing list