Stable ghc 9.14 rebased #60
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
angerman
force-pushed
the
stable-ghc-9.14-rebased
branch
5 times, most recently
from
9a76bd5 to
955a046
Compare
This change reverts part of !14544, which forces the bootstrap compiler to have ghc-internal. As such it breaks booting with ghc 9.8.4. A better solution would be to make this conditional on the ghc version in the cabal file!
…ernal If the boot compiler doesn't have ghc-internal use "<unavailble>" as the `cGhcInternalUnitId`. This allows booting with older compilers. The subsequent stage2 compilers will have the proper ghc-internal id from their stage1 compiler, that boots them.
mermaid is a common diagram format that can be inlined in markdown files, and e.g. github will even render it. This change adds support for mermaid diagram output to ghc-pkg.
This adds support to ghc-pkg to infer a package-db from a target name.
When the library dirs in the package conf files are not set up correctly, the JS linker will happily ignore such packages and not link against them, although they're part of the link plan. Fixes #26383
Make the first simple optimization pass after desugaring a real CoreToDo pass. This allows CorePlugins to decide whether they want to be executed before or after this pass.
Running the testsuite without Hadrian should set config.debug_rts correctly too.
It's more user-friendly to directly print the right thing instead of requiring the user to retry with the additional `-dppr-debug` flag.
When GHC is linked statically, the stdout C global variable that GHC uses isn't shared with the stdout C global variable used by loaded code. As a consequence, the latter must be explicitly flushed because GHC won't flush it before exiting.
This change adds more information about the symbol and addresses we try to relocate in the linker. This significantly helps when deubbging relocation issues reported by users.
…ith the other Ghc prefixed variables.
…roken on darwin/non-dynamic.
The referenced issue 20706 also doesn't list T13786 as a broken test.
There is no signal 0. The signal mask is 1-32.
…perly in the expected output.)
By mistake we tried to use deriveConstant without passing `--gcc-flag -fcommon` (which Hadrian does) and it failed. This patch adds deriveConstant support for constants stored in the .bss section so that deriveConstant works without passing `-fcommon` to the C compiler.
It's deprecated.
Fixes #26434 In detail, this does a number of things: * Makes GHC aware of 'extra-libraries-static' (this changes the package database format). * Adds a switch '-static-external' that will honour 'extra-libraries-static' to link external system dependencies statically. * Adds a new field to settings/targets: "ld supports verbatim namespace". This field is used by '-static-external' to conditionally use '-l:foo.a' syntax during linking, which is more robust than trying to find the absolute path to an archive on our own. * Adds a switch '-fully-static' that is meant as a high-level interface for e.g. cabal. This also honours 'extra-libraries-static'. This also attempts to clean up the confusion around library search directories. At the moment, we have 3 types of directories in the package database format: * library-dirs * library-dirs-static * dynamic-library-dirs However, we only have two types of linking: dynamic or static. Given the existing logic in 'mungeDynLibFields', this patch assumes that 'library-dirs' is really just nothing but a fallback and always prefers the more specific variants if they exist and are non-empty. Conceptually, we should be ok with even just one search dirs variant. Haskell libraries are named differently depending on whether they're static or dynamic, so GHC can conveniently pick the right one depending on the linking needs. That means we don't really need to play tricks with search paths to convince the compiler to do linking as we want it. For system C libraries, the convention has been anyway to place static and dynamic libs next to each other, so we need to deal with that issue anyway and it is outside of our control. But this is out of the scope of this patch. This patch is backwards compatible with cabal. Cabal should however be patched to use the new '-fully-static' switch.
"Executable" seems more appropriate.
Since we now ignore loading ANY rts dependency.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is on top of ghc-9.14:
[!14777] Fix loading of GHC.Internal.Prim module again (#25686) #65