- Jan 17, 2022
-
-
sheaf authored
-
-
- Jan 15, 2022
-
-
Eric Lindblad authored
-
-
Previously (9ebda74e) `environ` was added to `RtsSymbols` to ensure that environment was correctly propagated when statically linking. However, this introduced #20577 since platforms are inconsistent in whether they provide a prototype for `environ`. I fixed this by providing a prototype but while doing so dropped symbol-table entry, presumably thinking that it was redundant due to the entry in the mingw-specific table. Here I reintroduce the symbol table entry for `environ` and move libc symbols shared by Windows and Linux into a new macro, `RTS_LIBC_SYMBOLS`, avoiding this potential confusion.
-
- Jan 14, 2022
-
-
-
-
-
This reverts commit c0b854e9
-
-
- Jan 13, 2022
- Jan 12, 2022
-
-
Fixes #20928
-
(Fixes #10616 and #10617) Co-authored-by:
Roland Senn <rsx@bluewin.ch>
-
-
They are likely broken for the same reason as FreeBSD where the tests are already disabled.
-
The test currently times out waiting for end of stdin in getContents. The expected output indicates that nothing should come for the test to pass as written. It is unclear how the test was supposed to pass, but this looks like a sufficient hack to make it work.
-
Diagnostics for outofmem test on OpenBSD includes the amount of memory that it failed to allocate. This seems like an irrelevant detail that could change over time and isn't required for determining if test passed. Typical elided text is '(requested 2148532224 bytes)'
-
ASSERT should be used in situations where something very bad will happen later on if a certain invariant doesn't hold. The idea is that IF we catch the assertion earlier then it will be easier to work out what's going on at that point rather than at some indeterminate point in the future of the program. The assertions in Stats.c do not obey this philsophy and it is quite annoying if you are running a debug build (or a ticky compiler) and one of these assertions fails right at the end of your program, before the ticky report is printed out so you don't get any profiling information. Given that nothing terrible happens if these assertions are not true, or at least the terrible thing will happen in very close proximity to the assertion failure, these assertions use the new WARN macro which prints the assertion failure to stdout but does not exit the program. Of course, it would be better to fix these metrics to not trigger the assertion in the first place but if they did fail again in the future it is frustrating to be bamboozled in this manner. Fixes #20899
-
Part of #20889
-
The documentation states that the interactive flags should be use for any interactive expressions. The interactive flags are used when typechecking these expressions but not when printing. The session flags (modified by :set) are only used when loading a module. Fixes #20909
-
This makes it more similar to pprTrace, pprPanic etc.
-
The `GHC.Tc.Plugin.newWanted` function takes a `CtLoc` as an argument, but it used to discard the location information, keeping only the `CtOrigin`. It would then retrieve the source location from the `TcM` environment using `getCtLocM`. This patch changes this so that `GHC.Tc.Plugin.newWanted` passes on the full `CtLoc`. This means that authors of type-checking plugins no longer need to manually set the `CtLoc` environment in the `TcM` monad if they want to create a new Wanted constraint with the given `CtLoc` (in particular, for setting the `SrcSpan` of an emitted constraint). This makes the `newWanted` function consistent with `newGiven`, which always used the full `CtLoc` instead of using the environment. Fixes #20895
-
The pretty-printing of partially applied unboxed sums was incorrect, as we incorrectly dropped the first half of the arguments, even for a partial application such as (# | #) @IntRep @DoubleRep Int# which lead to the nonsensical (# DoubleRep | Int# #). This patch also allows users to write unboxed sum type constructors such as (# | #) :: TYPE r1 -> TYPE r2 -> TYPE (SumRep '[r1,r2]). Fixes #20858 and #20859.
-
Uses of a TyCon in a kind signature required users to enable DataKinds, which didn't make much sense, e.g. in type U = Type type MyMaybe (a :: U) = MyNothing | MyJust a Now the DataKinds error is restricted to data constructors; the use of kind-level type constructors is instead gated behind -XKindSignatures. This patch also adds a convenience pattern synonym for patching on both a TyCon or a TcTyCon stored in a TcTyThing, used in tcTyVar and tc_infer_id. fixes #20873
-
-
The bug it regresses didn't happen on this OS (no RLIMIT_AS) and the regression doesn't work (ulimit: -v: unknown option)
-
Previously we would unconditionally provide a declaration for `environ`, even if `<unistd.h>` already provided one. This would result in `-Werror` builds failing on some platforms. Also `#include <unistd.h>` to ensure that the declaration is visible. Fixes #20861.
-
This fixes serious skew in the performance numbers because the packages were build with core-lint. Fixes #20826
-
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
-
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
-
- Jan 07, 2022
-
-
that note was removed in 4196969c
-
We noticed that the structure of CoreUnfolding could leave double the amount of CoreExprs which were retained in the situation where the template but not all the predicates were forced. This observation was then confirmed using ghc-debug: ``` (["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 237) (["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1) (["ghc:GHC.Core:Case","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 12) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 1) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 78) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","ghc-prim:GHC.Types:False","THUNK_1_0"],Count 1) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 3) (["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0"],Count 1) (["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 31) (["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 4307) (["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 6) (["ghc:GHC.Core:Let","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 29) (["ghc:GHC.Core:Lit","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1) (["ghc:GHC.Core:Tick","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 36) (["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 1) (["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 6) (["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","ghc-prim:GHC.Types:True","THUNK_1_0"],Count 2) ``` Where we can see that the first argument is forced but there are still thunks remaining which retain the old expr. For my test case (a very big module, peak of 3 000 000 core terms) this reduced peak memory usage by 1G (12G -> 11G). Fixes #20905
-