- Nov 17, 2019
-
-
Ben Gamari authored
Bumps haddock submodule.
-
- Nov 14, 2019
-
-
Ben Gamari authored
Metric Increase: T4801
-
- Nov 13, 2019
-
-
Previously an import cycle between Type and TyCoRep meant that several functions in TyCoRep ended up SOURCE import coreView. This is quite unfortunate as coreView is intended to be fused into a larger pattern match and not incur an extra call. Fix this with a bit of restructuring: * Move the functions in `TyCoRep` which depend upon things in `Type` into `Type` * Fold contents of `Kind` into `Type` and turn `Kind` into a simple wrapper re-exporting kind-ish things from `Type` * Clean up the redundant imports that popped up as a result Closes #17441. Metric Decrease: T4334
-
- Nov 08, 2019
-
-
- Nov 06, 2019
-
-
This checks the configuration about python3-sphinx. We need python3-sphinx instead of python2-sphinx to build documentation. The approach is as follows: * Check python3 version with custom `conf.py` invoked from sphinx-build` executable * Place custom `conf.py` into new `utils/check-sphinx` directory If sphinx is for python2 not python3, it's treated as config ERROR instead of WARN. See also #17346 and #17356.
-
- Nov 03, 2019
-
-
Since the Trees That Grow effort started, we had `type LPat = Pat`. This is so that `SrcLoc`s would only be annotated in GHC's AST, which is the reason why all GHC passes use the extension constructor `XPat` to attach source locations. See #15495 for the design discussion behind that. But now suddenly there are `XPat`s everywhere! There are several functions which dont't cope with `XPat`s by either crashing (`hsPatType`) or simply returning incorrect results (`collectEvVarsPat`). This issue was raised in #17330. I also came up with a rather clean and type-safe solution to the problem: We define ```haskell type family XRec p (f :: * -> *) = r | r -> p f type instance XRec (GhcPass p) f = Located (f (GhcPass p)) type instance XRec TH f = f p type LPat p = XRec p Pat ``` This is a rather modular embedding of the old "ping-pong" style, while we only pay for the `Located` wrapper within GHC. No ping-ponging in a potential Template Haskell AST, for example. Yet, we miss no case where we should've handled a `SrcLoc`: `hsPatType` and `collectEvVarsPat` are not callable at an `LPat`. Also, this gets rid of one indirection in `Located` variants: Previously, we'd have to go through `XPat` and `Located` to get from `LPat` to the wrapped `Pat`. Now it's just `Located` again. Thus we fix #17330.
-
- Oct 29, 2019
-
-
This reverts commit aa31ceaf as suggested in #17392.
-
- Oct 28, 2019
-
-
Use FlexibleInstances for `Outputable (* p)` instead of match-all instances with equality constraints In #17304, Richard and Simon dicovered that using `-XFlexibleInstances` for `Outputable` instances of AST data types means users can provide orphan `Outputable` instances for passes other than `GhcPass`. Type inference doesn't currently to suffer, and Richard gave an example in #17304 that shows how rare a case would be where the slightly worse type inference would matter. So I went ahead with the refactoring, attempting to fix #17304.
-
- Oct 23, 2019
-
-
19 times out of 20 we already have dynflags in scope. We could just always use `return dflags`. But this is in fact not free. When looking at some STG code I noticed that we always allocate a closure for this expression in the heap. Clearly a waste in these cases. For the other cases we can either just modify the callsite to get dynflags or use the _D variants of withTiming I added which will use getDynFlags under the hood.
-
- Oct 22, 2019
-
-
This patch adds support for the s390x architecture for the LLVM code generator. The patch includes a register mapping of STG registers onto s390x machine registers which enables a registerised build.
-
FreeBSD does not support GNU libc, so it makes no sense to use this triple. Most likely previous builds were just using the FreeBSD libc instead of gnueabihf. To fix this, we should just use armv6-unknown-freebsd and armv7-unknown-freebsd triples. Note that both of these are actually "soft-float", not "hard-float". FreeBSD has never officially released hard-float arm32: https://wiki.freebsd.org/ARMTier1
-
- Oct 20, 2019
-
-
Tamar Christina authored
-
- Oct 18, 2019
-
-
Ben Gamari authored
This were previously quite unclear and will change a bit under the non-moving collector so let's clear this up now.
-
- Oct 16, 2019
-
-
It came back to life in 381c3ae3 by mistake.
-
- Oct 09, 2019
-
-
To avoid polluting the macro namespace
-
- Oct 08, 2019
-
-
This ensure that it blurts an error on missing references.
-
- Oct 07, 2019
-
-
We no longer support booting from older GHC since 527bcc41.
-
As described in the new Note [LLVM Configuration] in SysTools, we now load llvm-targets and llvm-passes lazily to avoid the overhead of doing so when -fllvm isn't used (also known as "the common case"). Noticed in #17003. Metric Decrease: T12234 T12150
-
- Oct 05, 2019
-
-
This was done in Nixpkgs, but never upstreamed. Musl is pretty much the same as gnu, but with a different libc. I’ve used the same values for everything.
-
-
The generated headers are now generated per stage, which means we can skip hacks like `ghc_boot_platform.h` and just have that be the stage 0 header as proper. In general, stages are to be embraced: freely generate everything in each stage but then just build what you depend on, and everything is symmetrical and efficient. Trying to avoid stages because bootstrapping is a mind bender just creates tons of bespoke mini-mind-benders that add up to something far crazier. Hadrian was pretty close to this "stage-major" approach already, and so was fairly easy to fix. Make needed more work, however: it did know about stages so at least there was a scaffold, but few packages except for the compiler cared, and the compiler used its own counting system. That said, make and Hadrian now work more similarly, which is good for the transition to Hadrian. The merits of embracing stage aside, the change may be worthy for easing that transition alone.
-
- Sep 25, 2019
-
-
The minimum required GHC version for bootstrapping is 8.6, so we can get rid of some unneeded `#if `__GLASGOW_HASKELL__` CPP guards, as well as one `MIN_VERSION_ghc_prim(0,5,3)` guard (since GHC 8.6 bundles `ghc-prim-0.5.3`).
-
- Sep 20, 2019
-
-
Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
-
- Sep 17, 2019
-
-
Until 0472f0f6 there was a meaningful host vs target distinction (though it wasn't used right, in genapply). After that, they did not differ in meaningful ways, so it's best to just only keep one.
-
- Sep 13, 2019
-
-
- Sep 12, 2019
-
-
------------------------- Metric Increase: haddock.Cabal T4029 -------------------------
-
- Sep 09, 2019
-
-
Sylvain Henry authored
Add StgToCmm module hierarchy. Platform modules that are used in several other places (NCG, LLVM codegen, Cmm transformations) are put into GHC.Platform.
-
- Sep 07, 2019
-
-
Mainly we now generate this data PlatformConstants = PlatformConstants { pc_CONTROL_GROUP_CONST_291 :: Int, pc_STD_HDR_SIZE :: Int, pc_PROF_HDR_SIZE :: Int, pc_BLOCK_SIZE :: Int, } instead of data PlatformConstants = PlatformConstants { pc_platformConstants :: () , pc_CONTROL_GROUP_CONST_291 :: Int , pc_STD_HDR_SIZE :: Int , pc_PROF_HDR_SIZE :: Int , pc_BLOCK_SIZE :: Int ... } The first field has no use and according to (removed) comments it was to make code generator's work easier.. if anything this version is simpler because it has less repetition (the commas in strings are gone).
-
- Aug 07, 2019
-
-
- Jul 21, 2019
-
-
As fromFlag is partial. The only case where we used fromFlag is when determining whether to strip libraries; we now assume that we shouldn't.
-
- Jul 14, 2019
-
-
These are unexploded minds as far as the linter is concerned. I don't want to hit in my MRs by mistake! I did this with `sed`, and then rolled back some changes in the docs, config.guess, and the linter itself.
-
- Jul 10, 2019
-
-
The code, including the generated module with the version, is now in ghc-boot. Config.hs reexports stuff as needed, ghc-pkg doesn't need any tricks at all.
-
These prevent multi-target builds. They were gotten rid of in 3 ways: 1. In the compiler itself, replacing `#if` with runtime `if`. In these cases, we care about the target platform still, but the target platform is dynamic so we must delay the elimination to run time. 2. In the compiler itself, replacing `TARGET` with `HOST`. There was just one bit of this, in some code splitting strings representing lists of paths. These paths are used by GHC itself, and not by the compiled binary. (They are compiler lookup paths, rather than RPATHS or something that does matter to the compiled binary, and thus would legitamentally be target-sensative.) As such, the path-splitting method only depends on where GHC runs and not where code it produces runs. This should have been `HOST` all along. 3. Changing the RTS. The RTS doesn't care about the target platform, full stop. 4. `includes/stg/HaskellMachRegs.h` This file is also included in the genapply executable. This is tricky because the RTS's host platform really is that utility's target platform. so that utility really really isn't multi-target either. But at least it isn't an installed part of GHC, but just a one-off tool when building the RTS. Lying with the `HOST` to a one-off program (genapply) that isn't installed doesn't seem so bad. It's certainly better than the other way around of lying to the RTS though not to genapply. The RTS is more important, and it is installed, *and* this header is installed as part of the RTS.
-
- Jul 09, 2019
-
-
Ryan Scott authored
To avoid having to `panic` any time a TTG extension constructor is consumed, this MR introduces an uninhabited 'NoExtCon' type and uses that in every extension constructor's type family instance where it is appropriate. This also introduces a 'noExtCon' function which eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates a 'Void'. I also renamed the existing `NoExt` type to `NoExtField` to better distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of code churn resulting from this. Bumps the Haddock submodule. Fixes #15247.
-
- Jun 26, 2019
-
-
This commit partly reverts e69619e9 commit by reintroducing Sf_SafeInferred SafeHaskellMode. We preserve whether module was declared or inferred Safe. When declared-Safe module imports inferred-Safe, we warn. This inferred status is volatile, often enough it's a happy coincidence, something which cannot be relied upon. However, explicitly Safe or Trustworthy packages won't accidentally become Unsafe. Updates haddock submodule.
-
-
- Jun 24, 2019
-
-
- Jun 20, 2019
-
-
This matches GHC itself getting the target platform from there.
-
- Jun 16, 2019
-
-
Before this patch, runghc would only run the GHC detection logic on Windows and assume that it was invoked through a wrapper script on all other platforms. This patch lifts this limitation and makes that logic work for the scenario where someone is calling the runghc executable directly, without passing an explicit path to GHC.
-
This disables optimisation when building Cabal for Hadrian and stage0 `ghc-cabal`. Cabal is performance critical in neither case nor will any performance difference here be visible to the end-user. See #16817.
-
