[Git][ghc/ghc][wip/jade/ast] 13 commits: Deprecation for WarnCompatUnqualifiedImports
Hassan Al-Awwadi (@hassan.awwadi)
gitlab at gitlab.haskell.org
Mon Oct 7 22:38:41 UTC 2024
Hassan Al-Awwadi pushed to branch wip/jade/ast 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
- - - - -
4a2f0f13 by Alan Zimmerman at 2024-10-07T05:16:54-04:00
EPA: Remove unused hsCaseAnnsRest
We never populate it, so remove it.
- - - - -
5099057b by John Paul Adrian Glaubitz at 2024-10-07T05:17:40-04:00
rts: Fix invocation of __ieee_set_fp_control() on alpha-linux
Fixes the following error when building GHC on alpha-linux:
rts/posix/Signals.c: In function ‘initDefaultHandlers’:
rts/posix/Signals.c:709:5: error:
error: implicit declaration of function ‘ieee_set_fp_control’ [-Wimplicit-function-declaration]
709 | ieee_set_fp_control(0);
| ^~~~~~~~~~~~~~~~~~~
|
709 | ieee_set_fp_control(0);
|
- - - - -
c9590ba0 by Teo Camarasu at 2024-10-07T05:18:17-04:00
Add changelog entries for !12479
- - - - -
bf9c9566 by Matthew Pickering at 2024-10-07T13:19:30-04:00
javascript: Read fields of ObjectBlock lazily
When linking a module with a large dependency footprint too much of the
object files were forced during linking. This lead to a large amount of
memory taken up by thunks which would never be forced
On the PartialDownsweep test this halves the memory required (from 25G
to 13G).
Towards #25324
-------------------------
Metric Increase:
size_hello_obj
-------------------------
- - - - -
571329df by Matthew Pickering at 2024-10-07T13:20:06-04:00
ci: Run the i386 validation job when i386 label is set
This is helpful when making changes to base and must update the
javascript and i386 base exports files.
- - - - -
e68f9aaf by Matthew Pickering at 2024-10-07T13:20:42-04:00
Rewrite partitionByWorkerSize to avoid pattern match checker bug
With `-g3` the pattern match checker would warn about these incomplete
patterns. This affects the debug_info builds on CI.
```
Pattern match(es) are non-exhaustive
In an equation for ‘go’:
Patterns of type ‘[a]’, ‘[a]’, ‘[SpecFailWarning]’ not matched:
(_:_) _ _
|
2514 | go [] small warnings = (small, warnings)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
Workaround for #25338
- - - - -
8e2e925f by Hassan Al-Awwadi at 2024-10-08T00:33:30+02:00
The main purpose of this commit is to rip RdrName out of FieldOcc, and
as a side note it has simplified the method we use to deal with ambiguity
somewhat.
To do the first, we make FieldOccs store (LIdP p) instead of always
storing Located RdrName, and moved the readername to the extension
points where necessary.
For the second, well, we just turn an ambiguous RdrName into a unbound
Name through mkUnboundName. Later during disambiguateRecordBinds of the
type checking phase, we will try and do type-directed disambiguation based
on the rdrName field (for now), so this hack works out fine.
See Note [Ambiguous FieldOcc in record updates] for more details.
There are two additional minor changes in this commit:
* The HsRecSel constructor of HsExpr has been moved to the extension
constuctors, since its really GHC specific.
* HsProjection no longer has a Located DotFieldOcc as a field, but just a
regular DotFieldOcc, since DotFieldOcc already wraps a located
FieldLabelString
co-authored by: @Jade <Jade512 at proton.me>
@Rodrigo Mesquita <rodrigo.m.mesquita at gmail.com>
- - - - -
30 changed files:
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Docs.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Fixity.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/StgToJS/Object.hs
- compiler/GHC/StgToJS/Types.hs
- compiler/GHC/Tc/Gen/Expr.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4e2d3926a2d547f7fa072fa52ee9de2b168a6e89...8e2e925f4d15858de046ad801f015af6c9cef159
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4e2d3926a2d547f7fa072fa52ee9de2b168a6e89...8e2e925f4d15858de046ad801f015af6c9cef159
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/05efbbe0/attachment-0001.html>
More information about the ghc-commits
mailing list