- May 20, 2022
-
-
The function breakTyVarCycle_maybe has been installed in a dark corner of GHC to catch some gremlins (a.k.a. occurs-check failures) who lurk there. But it previously only caught gremlins of the form (a ~ ... F a ...), where some of our intrepid users have spawned gremlins of the form (G a ~ ... F (G a) ...). This commit improves breakTyVarCycle_maybe (and renames it to breakTyEqCycle_maybe) to catch the new gremlins. Happily, the change is remarkably small. The gory details are in Note [Type equality cycles]. Test cases: typecheck/should_compile/{T21515,T21473}. (cherry picked from commit de8ed270) -
When passed `--use-system-libffi` then we shouldn't copy and install the headers from the system package. Instead the headers are expected to be available as a runtime dependency on the users system. Fixes #21485 #21487 ------------------------- Metric Decrease: T10421 T12234 T12425 T13035 T18923 -------------------------
-
- May 19, 2022
-
-
sheaf authored
Some of the other changes (e.g. reinstallable ghc) have not been backported to the ghc-9.2 branch, so we remove those CI jobs.
-
Hadrian doesn't actually depend on them as built-tools and normal usage where you want to compile GHC will pick up the tools before you run hadrian via the ./configure script. Not building an extra copy of alex and happy might also improve overall build-times when building from scratch.
-
-
Fixes #20984.
-
Fixes #21373
-
-
-
-
-
-
This patch adds the ability to fetch and store dependencies needed for boostrapping hadrian. By default the script will download the dependencies from the network but some package managers disallow network access so there are also options to build given a supplied tarball. The -s option allos you to provide the tarball bootstrap.py -d plan-bootstrap-8.10.5.json -w /path/to-ghc -s sources-tarball.tar.gz Which dependencies you need can be queried using the `list-sources` option. bootstrap.py list-sources -d plan-bootstrap-8.10.5.json This produces `fetch_plan.json` which tells you where to get each source from. You can instruct the script to create the tarball using the `fetch` option. bootstrap.py fetch -d plan-bootstrap-8.10.5.json -o sources-tarball.tar.gz Together these commands mean you can build GHC without needing cabal-install. Fixes #17103 -
-
'-x c++' was found to be required on Darwin Clang 11 and 12. '-std=c++' was found to be needed on Clang 12 but not 11.
-
These scripts are originally from the cabal-install repo with a few small tweaks. This utility allows you to build hadrian without cabal-install, which can be useful for packagers. If you are a developer then build hadrian using cabal-install. If you want to bootstrap with ghc-8.10.5 then run the ./bootstrap script with the `plan-bootstrap-8.10.5.json` file. bootstrap.py -d plan-bootstrap-8.10.5.json -w /path/to-ghc The result of the bootstrap script will be a hadrian binary in `_build/bin/hadrian`. There is a script (using nix) which can be used to generate the bootstrap plans for the range of supported GHC versions using nix. generate_bootstrap_plans Otherwise you can run the commands in ./generate_bootstrap_plans directly. Fixes #17103 -
The lack of INLNE arity was exposed by #21531. The fix is simple enough, if a bit clumsy. (cherry picked from commit 65d31d05)
-
-
This fixes #21479 See Note [Unquantified tyvars in a pattern synonym] While doing this, I found that some error messages pointed at the pattern synonym /name/, rather than the /declaration/ so I widened the SrcSpan to encompass the declaration. (cherry picked from commit bdc99cc2)
-
- May 13, 2022
-
-
(cherry picked from commit b2721819)
-
The package-specific include directories in Settings.Builders.Common.cIncludeDirs are now redundant since they now come from Cabal. Closes #20566. (cherry picked from commit 53cc93ae)
-
Previously we only took `extraLibDirs` and friends from the package description, ignoring any contribution from the `LocalBuildInfo`. Fix this. Fixes #20566. (cherry picked from commit 0950e2c4)
-
-
- May 12, 2022
-
-
This patch basically deletes some ad-hoc handling of Cabal Flags and replaces it with a correct query of the LocalBuildInfo. The flags in the local build info can be modified by users by passing hadrian options For example (!4331) ``` *.genapply.cabal.configure.opts += --flags=unregisterised ``` And all the flags specified by the `Cabal Flags` builder were already passed to configure properly using `--flags`. (cherry picked from commit c832ae93)
-
- May 10, 2022
-
-
Matthew Pickering authored
Updates bytestring submodule Ticket #21196
-
Clang on OpenBSD aborts compilation with this diagnostics: ``` % "inplace/bin/ghc-stage1" -optc-Wno-error=unused-label -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wno-aggregate-return -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist-install/build/./autogen -optc-Irts/include/../dist-install/build/include -optc-Irts/include/. -optc-Irts/. -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id rts -dcmm-lint -package-env - -i -irts -irts/dist-install/build -Irts/dist-install/build -irts/dist-install/build/./autogen -Irts/dist-install/build/./autogen -Irts/include/../dist-install/build/include -Irts/include/. -Irts/. -optP-DCOMPILING_RTS -optP-DFS_NAMESPACE=rts -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/linker/Elf.c -o rts/dist-install/build/linker/Elf.o rts/linker/Elf.c:2169:1: error: error: unused label 'dl_iterate_phdr_fail' [-Werror,-Wunused-label] | 2169 | dl_iterate_phdr_fail: | ^ dl_iterate_phdr_fail: ^~~~~~~~~~~~~~~~~~~~~ rts/linker/Elf.c:2172:1: error: error: unused label 'dlinfo_fail' [-Werror,-Wunused-label] | 2172 | dlinfo_fail: | ^ dlinfo_fail: ^~~~~~~~~~~~ 2 errors generated. ``` (cherry picked from commit 8961d632) -
This format has been used as a security exploit vector for decades now. Some operating systems (OpenBSD, Android, MSVC). It is targeted for removal in C2X standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2834.htm This requires extending the debug message function to return the number of bytes written (like printf(3)), to permit %n format specifier in one in one invocation of statsPrintf() in report_summary(). Implemented by Matthias Kilian (kili<AT>outback.escape.de) (cherry picked from commit e2c48b98)
-
(cherry picked from commit 284f33d6)
-
Previously we only preserved the bottom 64-bits of the callee-saved 128-bit XMM registers, in violation of the Win64 calling convention. Fix this. Fixes #21465. (cherry picked from commit baac50fb)
-
close #21417 (cherry picked from commit 60071076)
-
- May 09, 2022
-
-
For I assume performance reasons we don't record no-op replacements during unarise. This lead to problems with code like this: f = \(Eta_B0 :: VoidType) x1 x2 -> ... let foo = \(Eta_B0 :: LiftedType) -> g x y Eta_B0 in ... Here we would record the outer Eta_B0 as void rep, but would not shadow Eta_B0 inside `foo` because this arg is single-rep and so doesn't need to replaced. But this means when looking at occurence sites we would check the env and assume it's void rep based on the entry we made for the (no longer in scope) outer `Eta_B0`. Fixes #21396 and the ticket has a few more details. (cherry picked from commit 49bd7584) -
When passed a combination of `-N` and `-qn` options the cpu time for garbage collection was being vastly overcounted because the counters were not being zeroed appropiately. When -qn1 is passed, only 1 of the N avaiable GC threads is chosen to perform work, the rest are idle. At the end of the GC period, stat_endGC traverses all the GC threads and adds up the elapsed time from each of them. For threads which didn't participate in this GC, the value of the cpu time should be zero, but before this patch, the counters were not zeroed and hence we would count the same elapsed time on many subsequent iterations (until the thread participated in a GC again). The most direct way to zero these fields is to do so immediately after the value is added into the global counter, after which point they are never used again. We also tried another approach where we would zero the counter in yieldCapability but there are some (undiagnosed) siations where a capbility would not pass through yieldCapability before the GC ended and the same double counting problem would occur. Fixes #21082 (cherry picked from commit 840a6811)
-
-
-
Close #20231. (cherry picked from commit 1617fed3)
-
Note [Weak loop breakers] explains why we need to track variables free in RHS of rules. But we need to do this for /inactive/ rules as well as active ones, unlike the rhs_fv_env stuff. So we now have two fields in node Details, one for free vars of active rules, and one for free vars of all rules. This was shown up by #20820, which is now fixed. (cherry picked from commit ad835531)
-
-
-
Noticed build failures like ``` ghc-stage1: panic! (the 'impossible' happened) GHC version 9.3.20210721: pprCallishMachOp_for_C: MO_x64_Ne not supported! ``` on `--tagget=hppa2.0-unknown-linux-gnu`. The change does not fix all 32-bit unreg target problems, but at least allows linking final ghc binaries. Signed-off-by:Sergei Trofimovich <slyfox@gentoo.org> (cherry picked from commit 20173629) (cherry picked from commit 1f914ce7)
-
-
