- Aug 22, 2023
-
-
-
-
Matthew Pickering authoredThis doesn't work on slimmed down pipelines as the needed jobs don't exist. If you want to run test-primops then apply the label.
-
- Aug 21, 2023
-
-
This reverts commit 40425c50. See #23793 ------------------------- Metric Increase: T4801 T5321FD T5321Fun -------------------------
-
This reverts commit 00fb6e6b. See #23793
-
This reverts commit 8f3b3b78. See #23793
-
The test-primops CI job requires some additional builds in the validation pipeline, so we make sure to enable these jobs when test-primops label is set.
-
This commit adds 4 ways to trigger testing with test-primops. 1. Applying the ~test-primops label to a validate pipeline. 2. A manually triggered job on a validate pipeline 3. A nightly pipeline job 4. A release pipeline job Fixes #23695
-
-
- Aug 17, 2023
-
-
These are GC metadata and are not relevant to the end-user. Moreover, they are unstable which makes ghc-heap harder to test than necessary.
-
This test is very dependent upon GC behavior.
-
Here we refactor that treatment of the worker thread used by the nonmoving GC for concurrent marking, avoiding creating a new thread with every major GC cycle. As well, the new scheme is considerably easier to reason about, consolidating all state in one place, accessed via a small set of accessors with clear semantics.
-
These are largely superceded by support in the ghc-utils GDB extension.
-
Both info tables and the string table should be `const`
-
-
-
-
When a class instance has an Unsatisfiable constraint in its context and the user has not explicitly provided an implementation of a method, we now always provide a RHS of the form `unsatisfiable @msg`, even if the method has a default definition available. This ensures that, when deferring type errors, users get the appropriate error message instead of a possible runtime loop, if class default methods were defined recursively. Fixes #23816
-
Use `openSync` to implement `openat(AT_FDCWD...)`.
-
- Aug 16, 2023
-
-
Fixes #23821.
-
This matches up with the behaviour of ghc-toolchain, so that the output of both matches.
-
In ghc-toolchain, we were only /not/ configuring required flags when the user specified any flags at all for the of the HsCpp and Cpp tools. Otherwise, the linker takes into consideration the user specified flags to determine whether to search for a better linker implementation, but already configured the remaining GHC and platform-specific flags regardless of the user options. Other Tools consider the user options as a baseline for further configuration (see `findProgram`), so #23689 is not applicable. Closes #23689
-
-
-
This is important when we pass -I when setting up the windows toolchain.
-
If the user explicitly chooses to not set a MergeObjsCmd then it is correct to use Nothing for tgtMergeObjs field in the Target file.
-
-
If `MergeObjsCmd` is explicitly set to the empty string then we should assume that MergeObjs is just not supported. This is especially important for windows where we set MergeObjsCmd to "" in m4/fp_setup_windows_toolchain.m4.
-
We needed to remove -Wno-unused-command-line-argument from the arguments passed in order for the configure check to report correctly. See ghc/ghc!10976 (comment 516335)
-
The "format" mode takes an "--input" and "--ouput" target file and formats it. This is intended to be useful on windows where the configure/ghc-toolchain target files can't be diffed very easily because the path separators are different.
-
-
-
A normal triple may look like x86_64-unknown-linux but when cross-compiling you get $target set to a quad such as.. aarch64-unknown-linux-gnu Which should also match this check.
-
On some platforms - ie darwin, javascript etc we really do not want to allow the user to use any linker other than the default one as this leads to all kinds of bugs. Therefore it is a bit more prudant to add a whitelist which specifies on which platforms it might be possible to use a different linker.
-
-
On javascript there isn't a choice of toolchain but some of the configure checks were not accurately providing the correct answer. 1. The linker was reported as gnu LD because the --version output mentioned gnu LD. 2. The --target flag makes no sense on javascript but it was just ignored by the linker, so we add a special case to stop ghc-toolchain thinking that emcc supports --target when used as a linker.
-
While writing ghc-toolchain we noticed that the FP_PROG_LD_NO_COMPACT_UNWIND check is subtly wrong. Specifically, we pass -Wl,-no_compact_unwind to cc. However, ld.gold interprets this as -n o_compact_unwind, which is a valid argument. Fixes #23676
-
-
-
-
