- Sep 25, 2019
-
-
Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause a warning when no explicit deriving strategy is in use. This change adds an enable/suppress flag for it.
-
This commit adds three new files 1. A hie.yaml file to the project root which specifies to IDEs how to set up the correct environment for loading GHC. This currently specifies to call the `./hadrian/hie-bios` script. 2. A `hie.yaml` file for the hadrian subcomponent, which uses the `cabal` cradle type. 2. The `./hadrian/hie-bios` script which supplies the correct arguments for an IDE to start a session. With these two files it is possible to run ``` ghcide compiler/ ``` and successfully load all the modules for use in the IDE. or ``` ghcide --cwd hadrian/ src/ ``` to test loading all of Hadrian's modules. Closes #17194
-
The old test was wrong at least for gcc and the value -2287728808L. It also relied on implementation defined behaviour (right shift on a negative value), which might or might not be ok. Either way it's now a simple comparison which will always work.
-
- Sep 24, 2019
-
-
Due to #16555.
-
-
This bumps the CI Docker images to ghc/ci-images@990c5217.
-
Fixes #17181.
-
D3673 experienced reduce/reduce conflicts when trying to use opt_instance for associated data families. That was probably because the author tried to use it for Haskell98-syntax without also applying it to GADT-syntax, which actually leads to a reduce/reduce conflict. Consider the following state: ``` data . T = T data . T where T :: T ``` The parser must decide at this point whether or not to reduce an empty `opt_instance`. But doing so would also commit to either Haskell98 or GADT syntax! Good thing we also accept an optional "instance" for GADT syntax, so the `opt_instance` is there in both productions and there's no reduce/reduce conflict anymore. Also no need to inline `opt_instance`, how it used to be.
-
This commit adds -haddock option to Hadrian-based build system. To enable :doc command on GHCi, core libraries must be compiled with -haddock option. Especially, the `-haddock` option is essential for a release build. Assuming current GitLab CI condition (.gitlab-ci.yml), I add -haddock option to the default flavour only. This has already been done for Make-based build system. Please see #16415.
-
-
- Sep 23, 2019
-
-
Add a new optional failure handling for upsweep which continues the compilation on other modules if any of them has errors.
-
Currently, if you change these ^ flavour parameters, rebuilding is not triggered, since `programContext` doesn't set up a dependency on those values. Exposing these values via an oracle does set the dependency and properly triggers a rebuild of binaries. Several attempts to factor out these actions ended up in cyclic dependency here or there. I'm not absolutely happy with this variant either, but at least it works. ==== Issue repro: In UserSettings.hs: ``` dbgDynamic = defaultFlavour { name = "dbg-dynamic" , dynamicGhcPrograms = pure True, ... } dbgStatic = defaultFlavour { name = "dbg-static" , dynamicGhcPrograms = pure False ... } ``` Then in console: ``` $ hadrian/build.sh -j --flavour=dbg-dynamic ... does the build $ hadrian/build.sh -j --flavour=dbg-static ... does nothing, considers binaries up to date ```
-
-
-
-
-
-
-
This commit only fixes links and markdown syntax. [skip ci]
-
-
- Sep 22, 2019
-
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
[ci skip]
-
Daniel Gröber (dxld) authored
The 'cp' field really is only used when type==posTypeFresh so it's more space efficient to have it in the nextPos union.
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
This finally moves the newly generalised heap traversal code from the retainer profiler into it's own file.
-
Daniel Gröber (dxld) authored
A lot of these includes are presumably leftovers from when the retainer profiler still did it's own heap profiling.
-
Daniel Gröber (dxld) authored
Turns out some genius disabled warnings for RetainerProfile.c in the build system. That would have been good to know about five silent type mismatch crashes ago.. :)
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
Currently it is necessary for user code to expend at least one extra bit in the closure header just to know whether visit() should return true or false, to indicate if children should be traversed. The generic traversal code already has this information in the visited bit so simply pass it to the visit callback.
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
There's simply no need anymore for this whole business. Instead of individually traversing roots in retainRoot() we just push them all onto the stack and traverse everything in one go. This feature was not really used anyways. There is an `ASSERT(isEmptyWorkStack(ts))` at the top of retainRoot() which means there really can't ever have been any chunks at the toplevel. The only place where this was probably used is in traversePushStack but only way back when we were still using explicit recursion on the C callstack. Since the code was changed to use an explicit traversal-stack these stack-chunks can never escape one call to traversePushStack anymore. See commit 5f1d949a ("Remove explicit recursion in retainer profiling")
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
-
Daniel Gröber (dxld) authored
STATIC_INLINE already does what the code wanted here, no need to duplicate the functionality here.
-
Daniel Gröber (dxld) authored
These invariants don't seem to make any sense in the current code. The text talks about c_child_r as if it were an StgClosure, for which RSET() would make sense, but it's a retainer aka 'CostCentreStack*'.
-
Daniel Gröber (dxld) authored
A lot of comments and strings are still talking about old names, fix that.
-