- May 24, 2023
-
-
- Apr 21, 2023
-
-
- Add docs/index.html to .gitignore. It is created by ./hadrian/build docs, and it was the only file in Hadrian's templateRules not present in .gitignore. - Mention that MultiWayIf supports non-boolean guards - Remove documentation of optdll - removed in 2007, 763daed9 - Fix markdown syntax
-
- Nov 03, 2022
-
-
Cleans up git status if one sets -fwrite-ide-info in hadrian/ghci.
-
- Jul 18, 2022
-
-
While GHC's own aclocal.m4 is generated by the aclocal tool, other packages' aclocal.m4 are committed in the repository. Previously `.gitignore` included an entry which covered *any* file named `aclocal.m4`, which lead to quite some confusion (e.g. see #21740). Fix this by modifying GHC's `.gitignore` to only cover GHC's own `aclocal.m4`.
-
- Jun 20, 2022
-
-
Sebastian Graf authored
-
- May 17, 2022
-
-
Here we introduce a new "virtual" package into the initial package database, `system-cxx-std-lib`. This gives users a convenient, platform agnostic way to link against C++ libraries, addressing #20010. Fixes #20010.
-
- May 11, 2022
-
-
In the make bindists we generate documentation in docs/ghc-<VER> but the hadrian bindists generate docs/ghc/ so the path to the GHC API docs was wrong in the index.html file. Rather than make the hadrian and make bindists the same it was easier to assume that if you're using the mkDocs script that you're using hadrian bindists. Fixes #21509
-
- Apr 06, 2022
-
-
Fixes #21335. [ci skip]
-
- Mar 12, 2022
-
-
- Feb 21, 2022
-
-
This patch allows ghc and its dependencies to be built using a normal invocation of cabal-install. Each componenent which relied on generated files or additional configuration now has a Setup.hs file. There are also various fixes to the cabal files to satisfy cabal-install. There is a new hadrian command which will build a stage2 compiler and then a stage3 compiler by using cabal. ``` ./hadrian/build build-cabal ``` There is also a new CI job which tests running this command. For the 9.4 release we will upload all the dependent executables to hackage and then end users will be free to build GHC and GHC executables via cabal. There are still some unresolved questions about how to ensure soundness when loading plugins into a reinstalled GHC (#20742) which will be tighted up in due course. Fixes #19896
-
- Nov 13, 2021
-
-
This is, rather unintuitively, part of the goal of making the packages that make of the GHC distribution more freestanding. `ghcversion.h` is very simple, so we easily can move it out of the main build systems (make and Hadrian). By doing so, the RTS becomes less of a special case to those build systems as the header, already existing in the source tree, appears like any other. We could do this with the upcomming RTS configure, but it hardly matters because there is nothing platform-specific here, it is just versioning information like the other files the top-level configure can be responsible for.
-
- Nov 06, 2021
-
-
Primops types were dependent on the target word-size at *compiler* compilation time. It's an issue for multi-target as GHC may not have the correct primops types for the target. This patch fixes some primops types: if they take or return fixed 64-bit values they now always use `Int64#/Word64#`, even on 64-bit architectures (where they used `Int#/Word#` before). Users of these primops may now need to convert from Int64#/Word64# to Int#/Word# (a no-op at runtime). This is a stripped down version of !3658 which goes the all way of changing the underlying primitive types of Word64/Int64. This is left for future work. T12545 allocations increase ~4% on some CI platforms and decrease ~3% on AArch64. Metric Increase: T12545 Metric Decrease: T12545
-
We should strive to make our includes in terms of the RTS as much as possible. One place there that is not possible, the llvm version, we make a new tiny header Stage numbers are somewhat arbitrary, if we simple need a newer RTS, we should say so.
-
- Oct 31, 2021
-
-
These are best thought of as being part of the RTS. - After !6791, `ghcautoconf.h` won't be used by the compiler inappropriately. - `ghcversion.h` is only used once outside the RTS, which is `compiler/cbits/genSym.c`. Except we *do* mean the RTS GHC is built against there, so it's better if we always get get the installed version. - `ghcplatform.h` alone is used extensively outside the RTS, but since we no longer have a target platform it is perfectly safe/correct to get the info from the previous RTS. All 3 are exported from the RTS currently and in the bootstrap window. This commit just swaps directories around, such that the new headers may continue to be used in stage 0 despite the reasoning above, but the idea is that we can subsequently make more interesting changes doubling down on the reasoning above. In particular, in !6803 we'll start "morally" moving `ghcautonconf.h` over, introducing an RTS configure script and temporary header of its `AC_DEFINE`s until the top-level configure script doesn't define any more. Progress towards #17191
-
- Oct 29, 2021
-
-
This is the following find and replace: - `rts/dist` -> `rts/dist-install` # for paths - `rts_dist` -> `rts_dist-install` # for make rules and vars - `,dist` -> `,dist-install` # for make, just in rts/ghc.mk` Why do this? Does it matter when the RTS is just built once? The answer is, yes, I think it does, because I want the distdir--stage correspondence to be consistent. In particular, for #17191 and continuing from d5de970d I am going to make the headers (`rts/includes`) increasingly the responsibility of the RTS (hence their new location). However, those headers are current made for multiple stages. This will probably become unnecessary as work on #17191 progresses and the compiler proper becomes more of a freestanding cabal package (e.g. a library that can be downloaded from Hackage and built without any autoconf). However, until that is finished, we have will transitional period where the RTS and headers need to agree on dirs for multiple stages. I know the make build system is going away, but it's not going yet, so I need to change it to unblock things :).
-
- Aug 09, 2021
-
-
In order to make the packages in this repo "reinstallable", we need to associate source code with a specific packages. Having a top level `/includes` dir that mixes concerns (which packages' includes?) gets in the way of this. To start, I have moved everything to `rts/`, which is mostly correct. There are a few things however that really don't belong in the rts (like the generated constants haskell type, `CodeGen.Platform.h`). Those needed to be manually adjusted. Things of note: - No symlinking for sake of windows, so we hard-link at configure time. - `CodeGen.Platform.h` no longer as `.hs` extension (in addition to being moved to `compiler/`) so as not to confuse anyone, since it is next to Haskell files. - Blanket `-Iincludes` is gone in both build systems, include paths now more strictly respect per-package dependencies. - `deriveConstants` has been taught to not require a `--target-os` flag when generating the platform-agnostic Haskell type. Make takes advantage of this, but Hadrian has yet to.
-
- Jul 27, 2021
-
-
- May 05, 2021
-
-
- Feb 14, 2021
-
-
isovector recently noticed that it is broken and regardless it is superceded by `hadrian/ghci`.
-
- Feb 01, 2021
-
-
After commit 55ef3bdc, running `./configure` now generates a `driver/ghci/ghci-wrapper.cabal` file from `driver/ghci/ghci-wrapper.cabal.in`, which pollutes the `git` tree: ``` $ git status On branch master Your branch is up to date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) driver/ghci/ghci-wrapper.cabal nothing added to commit but untracked files present (use "git add" to track) ``` Since `driver/ghci/ghci-wrapper.cabal` is autogenerated, the sensible thing to do is to add it to `.gitignore`. While I was in town, I also added the standard `*.in` file disclaimer to `driver/ghci/ghci-wrapper.cabal.in`. [ci skip]
-
- Jan 30, 2021
-
-
This wraps the existing GHCi wrapper script (driver/ghci/ghci.c) in a cabal file and adds the package to Hadrian.
-
- Jan 24, 2021
-
-
[ci skip]
-
- Sep 10, 2020
-
-
Sebastian Graf authored
-
- Sep 01, 2020
-
-
Ignore files from "new style" cabal builds (dist-newstyle folders) and from clangd (C language server).
-
- Oct 14, 2019
-
-
When the users guide fails to build (as in #17346), a `docs/users_guide/.log` file will be generated with contents that look something like this: ``` WARNING: unknown config value 'latex_paper_size' in override, ignoring /home/rgscott/Software/ghc5/docs/users_guide/ghci.rst:3410: WARNING: u'ghc-flag' reference target not found: -pgmo ?option? /home/rgscott/Software/ghc5/docs/users_guide/ghci.rst:3410: WARNING: u'ghc-flag' reference target not found: -pgmo ?port? Encoding error: 'ascii' codec can't encode character u'\u27e8' in position 132: ordinal not in range(128) The full traceback has been saved in /tmp/sphinx-err-rDF2LX.log, if you want to report the issue to the developers. ``` This definitely should not be checked in to version control, so let's add this to `.gitignore`.
-
- Oct 05, 2019
-
-
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.
-
- Aug 04, 2019
-
-
Add some files generated by hadrian and some tooling files
-
- Jul 31, 2019
-
-
- 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.
-
- May 07, 2019
-
-
As of commit d37d91e9, the GHC build now autogenerates a `includes/dist/build/settings` file. To avoid dirtying the current `git` status, this adds `includes/dist` to `.gitignore`. [ci skip]
-
- Mar 22, 2019
-
-
- Mar 15, 2019
-
-
- Mar 06, 2019
-
-
The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
-
- Feb 28, 2019
-
-
This adds trace messages that include the processes name and as such make debugging and following the communication easier. It also adds a note regarding the fwd*Call proxy-communication logic between the proxy and the slave. The proxy will now also poll for 60s to wait for the remote iserv to come up. (Alternatively you can start the remote process beforehand; and just have iserv-proxy connect to it)
-
- Feb 20, 2019
-
-
Along the way, I discovered that `template-haskell.cabal` was hard-coding the GHC version (in the form of its `ghc-boot-th` version bounds), so I decided to make life a little simpler in the future by generating `template-haskell.cabal` with autoconf.
-
- Nov 26, 2018
-
-
Ryan Scott authored
Summary: Currently, the version numbers for `libiserv`, `iserv`, and `iserv-proxy` are hard-coded directly into their `.cabal` files. These are easy to forget to update, and in fact, this has already happened once (see #15866). Let's use `autoconf` to do this for us so that it is not forgotten in the future. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15866 Differential Revision: https://phabricator.haskell.org/D5302
-
- Nov 11, 2018
-
-
Summary: I tend to accumulate these and they are often quite useful to keep around. Reviewers: monoidal Reviewed By: monoidal Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5320
-
- Oct 02, 2018
-
-
Summary: allow -main-is to change export list for default module header, allowing one to change the entry point to one's program. Test Plan: ./validate Reviewers: bgamari, nomeata, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #13704 Differential Revision: https://phabricator.haskell.org/D5189
-
- Aug 06, 2018
-
-
Summary: My very last commit to D4904 removed -fobject-code. I should have tested this more thoroughly, because it is required to do a fresh ghci load, as some code uses unboxed tuples. One of my motivations for doing this was that if you run the script without passing -odir / -hidir, it would pollute the source tree with .hi and .o files. This also appeared to break subsequent builds. I've made it much less likely that this will happen by instead specifying -odir and -hidir within the ghci script rather than on the commandline. I plan to open a separate diff which adds a test that these scripts work. Until this patch is merged, the workaround is to do `./utils/ghc-in-ghci/run.sh -fobject-code` Reviewers: bgamari, alpmestan, monoidal Reviewed By: alpmestan, monoidal Subscribers: alpmestan, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D5015
-
- Jun 14, 2018
-
-
Vladislav Zavialov authoredSummary: Implement the "Embrace Type :: Type" GHC proposal, .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the -XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with -XDataKinds but not -XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and -XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in -XTypeInType into the -XPolyKinds and -XDataKinds extensions. * Introduce a new extension -XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748
-
