- Aug 28, 2023
-
-
sheaf authored
This commit accepts testsuite changes for the changes in the previous commit, which mean that TypeAbstractions is no longer implied by ScopedTypeVariables.
-
sheaf authored
This commit implements [amendment 604](https://github.com/ghc-proposals/ghc-proposals/pull/604/) to [GHC proposal 448](https://github.com/ghc-proposals/ghc-proposals/pull/448) by removing the implication of language extensions ScopedTypeVariables => TypeAbstractions To limit breakage, we now allow type arguments in constructor patterns when both ScopedTypeVariables and TypeApplications are enabled, but we emit a warning notifying the user that this is deprecated behaviour that will go away starting in GHC 9.12. Fixes #23776
-
Simon says this was fixed by commit 59202c80 Author: Sebastian Graf <sebastian.graf@kit.edu> Date: Fri Mar 31 17:35:22 2023 +0200 CorePrep: Eliminate EmptyCase and unsafeEqualityProof in CoreToStg instead We eliminate EmptyCase by way of `coreToStg (Case e _ _ []) = coreToStg e` now. The main reason is that it plays far better in conjunction with eta expansion (as we aim to do for arguments in CorePrep, #23083), because we can discard any arguments, `(case e of {}) eta == case e of {}`, whereas in `(e |> co) eta` it's impossible to discard the argument.
-
-
- Aug 27, 2023
-
-
The boot compiler was bumped to 9.4 in cebb5819. There is no point supporting older GHC versions with CPP.
-
- Aug 26, 2023
-
-
Artin Ghasivand authored
-
- Aug 25, 2023
-
-
-
The copyBytes function is provided by the import of Foreign. Fixes #23889
-
A warning can now be written with a category, e.g. {-# WARNInG in "x-c" e "d" #-} Keep track of the location of the 'in' keyword and string, as well as the original SourceText of the label, in case it uses character escapes. -
As of https://reviews.llvm.org/D103048 LLVM no longer supports the `-stack-alignment=...` flag. Instead this information is passed via a module flag metadata node. This requires dropping support for LLVM 11 and 12. Fixes #23870
-
-
These are useful in `GHC.Driver.Config.*`.
-
This omission appears to be an oversight.
-
-
- Aug 24, 2023
-
-
We want to make sure we don't end up with poor codegen performance resulting from -finfo-table-map again as in #23103. This test adds a performance test tracking total allocations while compiling ExactPrint with -finfo-table-map.
-
This commit greatly refactors the way we compute estimated provenance for stack info tables. Previously, this process was done using an entirely separate traversal of the whole Cmm code stream to build the map from info tables to source locations. The separate traversal is now fused with the Cmm code generation pipeline in GHC.Driver.Main. This results in very significant code generation speed ups when -finfo-table-map is enabled. In testing, this patch reduces code generation times by almost 30% with -finfo-table-map and -O0, and 60% with -finfo-table-map and -O1 or -O2 . Fixes #23103
-
This commit performs boot-file consistency checking for TyCons into checkValidTyCl. This ensures that we eagerly catch any mismatches, which prevents the compiler from seeing these inconsistencies and panicking as a result. See Note [TyCon boot consistency checking] in GHC.Tc.TyCl. Fixes #16127
-
- Aug 23, 2023
-
-
-
-
To warn users that these modules are internal and their interfaces may change with little warning. As proposed in Core Libraries Committee #146 [CLC146]. [CLC146]: https://github.com/haskell/core-libraries-committee/issues/146
-
The metric increase here isn't strictly due to this commit but it's a rather small, incidental change. Metric Increase: T8095 T13386 Metric Decrease: T8095 T13386 T18304 -
-
-
-
-
-
-
-
This commit changes how hints are handled in conjunction with constraint solver report messages. Instead of storing `[GhcHint]` in the TcRnSolverReport error constructor, we compute the hints depending on the underlying TcSolverReportMsg. This disentangles the logic and makes it easier to add new hints for certain errors.
-
-
For some reason there was an indirection via the Windres variable before setting WindresCmd. That indirection led to #23855. I then also noticed that these other variables were just not used anywhere when trying to work out what the correct condition was for this bit of the configure script.
-
-
The binary dist produced by `binary-dist` target doesn't work on windows because of the wrapper script the makefile installs. In order to not surprise any packagers we just give an error if someone tries to build the old binary-dist target rather than the reloc-binary-dist target.
-
We now build the relocatable bindist target on windows, which means we test and distribute the new method of creating a relocatable bindist.
-
This includes quite a lot of small fixes which fix the installation makefile to work on windows properly. This also required fixing the RelocatableBuild variable which seemed to have been broken for a long while. Sam helped me a lot writing this patch by providing a windows machine to test the changes. Without him it would have taken ages to tweak everything. Co-authored-by:sheaf <sam.derbyshire@gmail.com>
-
This adds a command line option to build a "relocatable" bindist. The bindist is created by first creating a normal bindist and then installing it using the `RelocatableBuild=YES` option. This creates a bindist without any wrapper scripts pointing to the libdir. The motivation for this feature is that we want to ship relocatable bindists on windows and this method is more uniform than the ad-hoc method which lead to bugs such as #23608 and #23476 The relocatable bindist can be built with the "reloc-binary-dist" target and supports the same suffixes as the normal "binary-dist" command to specify the compression style.
-
The config.mk.in script was relying on some variables which were supposed to be set by build.mk but therefore never were when used to install a bindist. Specifically * BUILD_PROF_LIBS to determine whether we had profiled libraries or not * DYNAMIC_GHC_PROGRAMS to determine whether we had shared libraries or not Not only were these never set but also not really accurate because you could have shared libaries but still statically linked ghc executable. In addition variables like GhcLibWays were just never used, so those have been deleted from the script. Now instead we generate a build.mk file which just directly specifies which RtsWays we have supplied in the bindist and whether we have DYNAMIC_GHC_PROGRAMS.
-
This commit splits up the windows toolchain setup logic into two functions. * FP_INSTALL_WINDOWS_TOOLCHAIN - deals with downloading the toolchain if it isn't already downloaded * FP_SETUP_WINDOWS_TOOLCHAIN - sets the environment variables to point to the correct place FP_SETUP_WINDOWS_TOOLCHAIN is abstracted from the location of the mingw toolchain and also the eventual location where we will install the toolchain in the installed bindist. This is the first step towards #23608
-
In Builder.hs, runBuilderWith mostly ignores the buildOptions in BuildInfo. This leads to hard to diagnose bugs as any build options you pass with runBuilderWithCmdOptions are ignored for many builders. Solution: Uniformly pass buildOptions to the invocation of cmd. Fixes #23845
-
This function is now deprecated from `bytestring`. Use `Foreign.Marshal.Utils.copyBytes` instead. Fixes #23880.
-
