Commits on Source (66)
-
This was caught by `ghcup-ci` failing and attempting to install a deb12 bindist on deb11. ``` configure: WARNING: m4/prep_target_file.m4: Expecting YES/NO but got in ArSupportsDashL_STAGE0. Defaulting to False. bin/ghc-toolchain-bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by bin/ghc-toolchain-bin) bin/ghc-toolchain-bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /tmp/tmp.LBhwvFbVoy/foobarbaz/.ghcup/tmp/ghcup-708d9668d5d82287/ghc-9.11.20240609-x86_64-unknown-linux/bin/../lib/x86_64-linux-ghc-9.11.20240609/libHSunix-2.8.5.1-inplace-ghc9.11.20240609.so) bin/ghc-toolchain-bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/tmp.LBhwvFbVoy/foobarbaz/.ghcup/tmp/ghcup-708d9668d5d82287/ghc-9.11.20240609-x86_64-unknown-linux/bin/../lib/x86_64-linux-ghc-9.11.20240609/libHSunix-2.8.5.1-inplace-ghc9.11.20240609.so) ``` Fixes #24974
cca7de25 -
- Remove dead code. - Remove `streamly` dependency. - Process files with `bytestring`. - Replace Unicode files parsers with the corresponding ones from the package `unicode-data-parser`. - Simplify cabal file and rename module - Regenerate `ghc-internal` Unicode files with new header
7b23ce8b -
Also remove ghc 9.7 requirement
4570319f -
-
-
ce76bf78
-
..Th bug in #24623 is randomly triggered by this MR!..
19bcfc9b -
This MR was triggered by #24868, but I found a number of bugs and infelicities in type-tidying as I went along. Highlights: * Fix to #24868 is in GHC.Tc.Errors.report_unsolved: avoid using the OccNames of /bound/ variables when tidying /free/ variables; see the call to `tidyAvoiding`. That avoid the gratuitous renaming which was the cause of #24868. See Note [tidyAvoiding] in GHC.Core.TyCo.Tidy * Refactor and document the tidying of open types. See GHC.Core.TyCo.Tidy Note [Tidying open types] Note [Tidying is idempotent] * Tidy the coercion variable in HoleCo. That's important so that tidied types have tidied kinds. * Some small renaming to make things consistent. In particular the "X" forms return a new TidyEnv. E.g. tidyOpenType :: TidyEnv -> Type -> Type tidyOpenTypeX :: TidyEnv -> Type -> (TidyEnv, Type)
7a08a025 -
2eac0288
-
e5d24cc2
-
This small change fixes #24944 See (SCF1) in Note [SpecConstr and strict fields]
246bc3a4 -
a5994380
-
Parsing this operation allows it to be tested using `test-primops` in a subsequent MR.
bd95553a -
e0099721 -
So we can freely modify the pats and the following item spacing will still be valid when exact printing. Closes #24862
118a1292 -
Fixes GHC crashing on `decomposeRuleLhs` due to ignoring coercion values. This happens when we have a RULE that does not type check, and enable `-fdefer-type-errors`. We prevent this to happen by rejecting RULES with an immediately LHS type error. Fixes #24026
db343324 -
Use runHsc' in runHsc so that both functions can't fall out of sync We're currently copying parts of GHC code to get structured warnings in HLS, so that we can recreate `hscTypecheckRenameWithDiagnostics` locally. Once we get this function into GHC we can drop the copied code in future versions of HLS.
e7a95662 -
-
This commit introduces the RTS flag `--read-tix-file=<yes|no>` which controls whether a preexisting .tix file is read in at the beginning of a program run. The default is currently `--read-tix-file=yes` but will change to `--read-tix-file=no` in a future release of GHC. For this reason, whenever a .tix file is read in a warning is emitted to stderr. This warning can be silenced by explicitly passing the `--read-tix-file=yes` option. Details can be found in the GHC proposal cited below. Users can query whether this flag has been used with the help of the module `GHC.RTS.Flags`. A new field `readTixFile` was added to the record `HpcFlags`. These changes have been discussed and approved in - GHC proposal 612: https://github.com/ghc-proposals/ghc-proposals/pull/612 - CLC proposal 276: https://github.com/haskell/core-libraries-committee/issues/276
13fdf788 -
As a `ModIface` often contains duplicated values that are not necessarily shared, we improve sharing by serialising the `ModIface` to an in-memory byte array. Serialisation uses deduplication tables, and deserialisation implicitly shares duplicated values. This helps reducing the peak memory usage while compiling in `--make` mode. The peak memory usage is especially smaller when generating interface files with core expressions (`-fwrite-if-simplified-core`). On agda, this reduces the peak memory usage: * `2.2 GB` to `1.9 GB` for a ghci session. On `lib:Cabal`, we report: * `570 MB` to `500 MB` for a ghci session * `790 MB` to `667 MB` for compiling `lib:Cabal` with ghc There is a small impact on execution time, around 2% on the agda code base.
f0e3cb6a -
To reduce memory usage of `ModIface`, we serialise `ModIface` to an in-memory byte array, which implicitly shares duplicated values. This serialised byte array can be reused to avoid work when we actually write the `ModIface` to disk. We introduce a new field to `ModIface` which allows us to save the byte array, and write it direclty to disk if the `ModIface` wasn't changed after the initial serialisation. This requires us to change absolute offsets, for example to jump to the deduplication table for `Name` or `FastString` with relative offsets, as the deduplication byte array doesn't contain header information, such as fingerprints. To allow us to dump the binary blob to disk, we need to replace all absolute offsets with relative ones. We introduce additional helpers for `ModIface` binary serialisation, which construct relocatable binary blobs. We say the binary blob is relocatable, if the binary representation can be moved and does not contain any absolute offsets. Further, we introduce new primitives for `Binary` that allow to create relocatable binaries, such as `forwardGetRel` and `forwardPutRel`. ------------------------- Metric Decrease: MultiLayerModulesDefsGhcWithCore Metric Increase: MultiComponentModules MultiLayerModules T10421 T12150 T12234 T12425 T13035 T13253-spj T13701 T13719 T14697 T15703 T16875 T18698b T18140 T18304 T18698a T18730 T18923 T20049 T24582 T5837 T6048 T9198 T9961 mhu-perf ------------------------- These metric increases may look bad, but they are all completely benign, we simply allocate 1 MB per module for `shareIface`. As this allocation is quite quick, it has a negligible impact on run-time performance. In fact, the performance difference wasn't measurable on my local machine. Reducing the size of the pre-allocated 1 MB buffer avoids these test failures, but also requires us to reallocate the buffer if the interface file is too big. These reallocations *did* have an impact on performance, which is why I have opted to accept all these metric increases, as the number of allocated bytes is merely a guidance. This 1MB allocation increase causes a lot of tests to fail that generally have a low allocation number. E.g., increasing from 40MB to 41MB is a 2.5% increase. In particular, the tests T12150, T13253-spj, T18140, T18304, T18698a, T18923, T20049, T24582, T5837, T6048, and T9961 only fail on i386-darwin job, where the number of allocated bytes seems to be lower than in other jobs. The tests T16875 and T18698b fail on i386-linux for the same reason.1bab7dde -
In particular mention possible uses for non-lifted types. Fixes #23100.
099992df -
5e75412b
-
-
Fixes #24909
1eb15c61 -
-
This has the additional benefit of getting rid of the -1 encoding (real registers start at 0.)
8ea0ba95 -
325422e0
-
64fba310 -
The BL constructor carried unused data in its third argument.
eb612fbc -
It is only used there, simplifies the use of `Fixity` in the rest of the code, and is moved into a TTG extension point. Precedes !12842, to simplify it
b0300503 -
Deprecates the following modules according to clc-proposal #217: https://github.com/haskell/core-libraries-committee/issues/217 * GHC.TypeNats.Internal * GHC.TypeLits.Internal * GHC.ExecutionStack.Internal Closes #24998
842e119b -
Considering that the parser used to create a Bag of binds using a cons-based approach, it can be also done using lists. The operations in the compiler don't really require Bag. By using lists, there is no dependency on GHC.Data.Bag anymore from the AST. Progress towards #21592
24e89c40 -
This MR fixes #24938. The underlying problem was tha the test for "does this implication bring in scope any equalities" was plain wrong. See Note [Tracking Given equalities] and Note [Let-bound skolems] both in GHC.Tc.Solver.InertSet. Then * Test LocalGivenEqs succeeds for a different reason than before; see (LBS2) in Note [Let-bound skolems] * New test T24938a succeeds because of (LBS2), whereas it failed before. * Test LocalGivenEqs2 now fails, as it should. * Test T224938, the repro from the ticket, fails, as it should.
04f5bb85 -
This MR tackles #24623 and #23113 The main change is to give a clearer notion of "worker/wrapper arity", esp for join points. See GHC.Core.Opt.DmdAnal Note [Worker/wrapper arity and join points] This Note is a good summary of what this MR does: (1) The "worker/wrapper arity" of an Id is * For non-join-points: idArity * The join points: the join arity (Id part only of course) This is the number of args we will use in worker/wrapper. See `ww_arity` in `dmdAnalRhsSig`, and the function `workWrapArity`. (2) A join point's demand-signature arity may exceed the Id's worker/wrapper arity. See the `arity_ok` assertion in `mkWwBodies`. (3) In `finaliseArgBoxities`, do trimBoxity on any argument demands beyond the worker/wrapper arity. (4) In WorkWrap.splitFun, make sure we split based on the worker/wrapper arity (re)-computed by workWrapArity.
9a757a27 -
-
cd512234 -
Don't support parsing bswap8, since bswap8 is not really an operation and would have to be implemented as a no-op (and currently is not implemented at all). Fixes #25002
8a8ff8f2 -
-
This pragma was accidentally introduced in 648fd73a The top-level cost centres lead to a lack of optimisation when compiling with profiling.
7b079378 -
haddock: Remove unused pragmata, qualify usages of Data.List functions, add more sanity checking flags by default This commit enables some extensions and GHC flags in the cabal file in a way that allows us to reduce the amount of prologuing on top of each file. We also prefix the usage of some List functions that removes ambiguity when they are also exported from the Prelude, like foldl'. In general, this has the effect of pointing out more explicitly that a linked list is used. Metric Increase: haddock.Cabal haddock.base haddock.compilerc872e09b -
8c87d4e1
-
When matching a template variable to an expression, we check that it has the same type as the matched expression. But if the variable `f` has type `A -> B` while the expression `e` has type `A %1 -> B`, the match was previously rejected. A principled solution would have `f` substituted by `\(%Many x) -> e x` or some other appropriate coercion. But since linearity is not properly checked in Core, we can be cheeky and simply ignore multiplicity while matching. Much easier. This has forced a change in the linter which, when `-dlinear-core-lint` is off, must consider that `a -> b` and `a %1 -> b` are equal. This is achieved by adding an argument to configure the behaviour of `nonDetCmpTypeX` and modify `ensureEqTys` to call to the new behaviour which ignores multiplicities when comparing two `FunTy`. Fixes #24725.
568de8a5 -
This MR speeds up type equality, triggered by perf regressions that showed up when fixing #24725 by parameterising type equality over whether to ignore multiplicity. The changes are: * Do not use `nonDetCmpType` for type /equality/. Instead use a specialised type-equality function, which we have always had! `nonDetCmpType` remains, but I did not invest effort in refactoring or optimising it. * Type equality is parameterised by - whether to expand synonyms - whether to respect multiplicities - whether it has a RnEnv2 environment In this MR I systematically specialise it for static values of these parameters. Much more direct and predictable than before. See Note [Specialising type equality] * We want to avoid comparing kinds if possible. I refactored how this happens, at least for `eqType`. See Note [Casts and coercions in type comparison] * To make Lint fast, we want to avoid allocating a thunk for <msg> in ensureEqTypes ty1 ty2 <msg> because the test almost always succeeds, and <msg> isn't needed. See Note [INLINE ensureEqTys] Metric Decrease: T13386 T5030
c8a8727e -
21fc180b
-
This is possible now that #22229 is fixed.
d640a3b6 -
After #22229 had been fixed, we can finally derive the `Lift` instance for the TH AST, as proposed by Ryan Scott in https://mail.haskell.org/pipermail/libraries/2015-September/026117.html. Fixes #14030, #14296, #21759 and #24560. The residency of T24471 increases by 13% because we now load `AnnLookup` from its interface file, which transitively loads the whole TH AST. Unavoidable and not terrible, I think. Metric Increase: T24471
33fee6a2 -
If a user has configured CDPATH on their system then `cd lib` may change into an unexpected directory during the installation process. If you write `cd ./lib` then it will not consult `CDPATH` to determine what you mean. I have added a check on ghcup-ci to verify that the bindist installation works in this situation. Fixes #24951
383c01a8 -
The pervasive usage of DynFlags (the parsed command-line options passed to ghc) blurs the border between different components of Haddock, and especially those that focus solely on printing text on the screen. In order to improve the understanding of the real dependencies of a function, the pretty-printer options are made concrete earlier in the pipeline instead of late when pretty-printing happens. This also has the advantage of clarifying which functions actually require DynFlags for purposes other than pretty-printing, thus making the interactions between Haddock and GHC more understandable when exploring the code base. See Henry, Ericson, Young. "Modularizing GHC". https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf. 2022
5759133f -
To allow rules to be written on the concrete implementation of `compare` for `Int` and `Word`, we need to have an `INLINE [1]` pragma on these functions, following the `matching_overloaded_methods_in_rules` note in `GHC.Classes`. CLC proposal https://github.com/haskell/core-libraries-committee/issues/179 Fixes #22643
749e089b -
db033639
-
Improves the error message for when `ghc-toolchain` fails to read a valid `Target` value from a file (in doFormat mode).
14308a8f -
6e7cfff1
-
It is better to fail earlier if the configure step fails rather than carrying on for a more obscure error message.
958d6931 -
f48d157d
-
-
It is non-obvious whether the toolchain configuration should use full-paths to tools or simply their names. In addressing #24574, we've decided to prefer executable names over paths, ultimately, because the bindist configure script already does this, thus is the default in ghcs out there. Updates the in-tree configure script to prefer tool names (`AC_CHECK_TOOL` rather than `AC_PATH_TOOL`) and `ghc-toolchain` to ignore the full-path-result of `findExecutable`, which it previously used over the program name. This change doesn't undo the fix in bd92182c because `AC_CHECK_TOOL` still takes into account the target triples, unlike `AC_CHECK_PROG/AC_PATH_PROG`.
665e653e -
We introduced a configuration step for the javascript preprocessor, but only did so for the in-tree configure script. This commit makes it so that we also configure the javascript preprocessor in the configure shipped in the compiler bindist.
463716c2 -
LlvmTarget was being set and substituted in the in-tree configure, but not in the configure shipped in the bindist. We want to set the LlvmTarget to the canonical LLVM name of the platform that GHC is targetting. Currently, that is going to be the boostrapped llvm target (hence the code which sets LlvmTarget=bootstrap_llvm_target).
e99cd73d -
4199aafe
-
f599d816
-
haddock: Move the usage of mkParserOpts directly to ppHyperlinkedModuleSource in order to avoid passing a whole DynFlags Follow up to !12931
8f4b799d -
This will be reintroduced with a properly ignored commit when the cabal files are themselves formatted for good.
210cf1cd -
Sign hints for parameters are in the second component of the pair. Fixes #23034
7fe85b13 -
-
Fabricio de Sousa Nascimento authored
Changes the error message when trying to lookup names on GRE that `must_have_parent` but we get an `AmbiguousOccurrence`. The new behavior now points the user to the missing name, instead of the name clash which would be unhelpful in solving their compiling issue. Fixes #24452
f0d7cd07
Showing
- .gitlab-ci.yml 2 additions, 2 deletions.gitlab-ci.yml
- .gitlab/ci.sh 1 addition, 1 deletion.gitlab/ci.sh
- .gitlab/generate-ci/gen_ci.hs 1 addition, 0 deletions.gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml 80 additions, 11 deletions.gitlab/jobs.yaml
- .gitlab/rel_eng/mk-ghcup-metadata/mk_ghcup_metadata.py 1 addition, 1 deletion.gitlab/rel_eng/mk-ghcup-metadata/mk_ghcup_metadata.py
- compiler/GHC.hs 29 additions, 1 deletioncompiler/GHC.hs
- compiler/GHC/Builtin/PrimOps.hs 0 additions, 1 deletioncompiler/GHC/Builtin/PrimOps.hs
- compiler/GHC/Builtin/Types.hs 9 additions, 1 deletioncompiler/GHC/Builtin/Types.hs
- compiler/GHC/Cmm/Parser.y 5 additions, 1 deletioncompiler/GHC/Cmm/Parser.y
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs 4 additions, 4 deletionscompiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs 6 additions, 12 deletionscompiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs 3 additions, 3 deletionscompiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs 1 addition, 1 deletioncompiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs 1 addition, 1 deletioncompiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs 10 additions, 16 deletionscompiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/Core/DataCon.hs 1 addition, 1 deletioncompiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Lint.hs 103 additions, 75 deletionscompiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Multiplicity.hs 8 additions, 1 deletioncompiler/GHC/Core/Multiplicity.hs
- compiler/GHC/Core/Opt/DmdAnal.hs 156 additions, 81 deletionscompiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/SpecConstr.hs 17 additions, 2 deletionscompiler/GHC/Core/Opt/SpecConstr.hs