- Oct 11, 2024
-
-
We should be free to import things from Language.Haskell.Syntax in GHC modules. Therefore the the boot file for the loop between ImpExp and GHC.Hs.Doc was in the wrong place. Issue #21592
-
As noted in #25362, these incomplete matches were previously not being warned about. They were easily addressed by use of `GHC.Internal.Event.Windows.withException`. Closes #25362.
-
This patch drops obsolete libffi Makefile from the tree, given it's completely unused since removal of make build system in !7094.
-
-
-
-
-
This MR fixes #25325 See GHC.Tc.Types.Constraint, Note [Insoluble Wanteds], especially (IW2) There is a small change in the error message for T14172, but it looks entirely acceptable to me.
-
-
This patch makes GHC bail out with an proper error message when it's not configured with LLVM but users attempt to pass -fllvm, see #25011 and added comment for details. Fixes #25011 Co-authored-by:Rodrigo Mesquita <rodrigo.m.mesquita@gmail.com>
-
The main purpose of this commit is to rip RdrName out of FieldOcc, in accordance with #21592, and as a side note it has simplified the method we use to deal with ambiguity somewhat. To do the first, we make FieldOccs store (LIdP p) instead of always storing Located RdrName, and moved the readername to the extension points where necessary. For the second, well, we just turn an ambiguous RdrName into a unbound Name through mkUnboundName. Later during disambiguateRecordBinds of the type checking phase, we will try and do type-directed disambiguation based on the rdrName field (for now), so this hack works out fine. See Note [Ambiguous FieldOcc in record updates] for more details. There are two additional minor changes in this commit: * The HsRecSel constructor of HsExpr has been moved to the extension constuctors, since its really GHC specific. * HsProjection no longer has a Located DotFieldOcc as a field, but just a regular DotFieldOcc, since DotFieldOcc already wraps a located FieldLabelString co-authored by: @Jade <Jade512@proton.me> @alt-romes <rodrigo.m.mesquita@gmail.com>
-
- Oct 10, 2024
-
-
If an IO manager backend throws, it will not actually have registered the file descriptor. However, at that point, the IO manager state was already updated to assume the file descriptor is being tracked, leading to errors and an eventual deadlock down the line as documented in the issue #21969. The fix for this is to undo the IO manager state change in case the backend throws (just as we already do when the backend signals that the file type is not supported). The exception then bubbles up to user code. That way we make sure that 1. the bookkeeping state of the IO manager is consistent with the actions taken by the backend, even in the presence of unexpected failures, and 2. the error is not silent and visible to user code, making failures easier to debug.
-
- Oct 09, 2024
-
-
EPA: introduce EpAnnLam for lambda annotationsi, and remove `glAA` from `Parser.y`, it is the same as `glR` EPA: Remove unused annotation from XOpApp EPA: Use EpToken for XNPat and XNegApp EPA: specific anns for XExplicitTuple / XTuplePat / sumPatParens. EPA: Use specific annotation for MultiIf EPA: Move annotations into FunRhs EPA: Remove [AddEpAnn] from SigPat and ExprWithTySig EPA: Remove [AddEpAnn] from ArithSeq EPA: Remove [AddEpAnn] from HsProc EPA: Remove [AddEpAnn] from HsStatic EPA: Remove [AddEpAnn] from BindStmt EPA: Remove [AddEpAnn] from TransStmt EPA: Remove [AddEpAnn] from HsTypedSplice EPA: Remove [AddEpAnn] from HsUntypedSpliceExpr
-
-
- Oct 08, 2024
-
-
-
This adds a validation job which tests that we can build a riscv64 cross compiler and build a simple program using it. We do not currently run the whole testsuite. Towards #25254 Co-authored-by:
Matthew Pickering <matthewtpickering@gmail.com>
-
- Oct 07, 2024
-
-
This commit updates the section of the user's guide pertaining to X86 feature flags with the following changes: - the NCG backend now supports SIMD, so remove all text that says the contrary, - the LLVM backend does not "automatically detect" features, so remove any text that makes that claim. -
This patch removes the ghciWithDebugger field from flavour config since it's actually not used anywhere.
-
The C calling convention / standard requires that arguments and their values are of the same type.
-
Fixes #25335
-
Closes #16479
-
-
This improves the performance of Cmm switch statements (compared to a chain of if statements.)
-
Instead, we use a dedicated DelayedError, which is emitted systematically on submultiplicity checks, but is suppressed if we can indeed solve the submultiplicity constraint with a reflexivity coercion. This way, we don't have to return anything from `tcSubMult`, which now looks like a regular constraint check, the rest is implementation detail. This removes all of the strange boilerplate that I'd been struggling with under the previous implementation. Even if submultiplicity checks are not properly constraints, this way it's contained entirely within a `WantedConstraint`. Much more pleasant. Closes #25128.
-
With `-g3` the pattern match checker would warn about these incomplete patterns. This affects the debug_info builds on CI. ``` Pattern match(es) are non-exhaustive In an equation for ‘go’: Patterns of type ‘[a]’, ‘[a]’, ‘[SpecFailWarning]’ not matched: (_:_) _ _ | 2514 | go [] small warnings = (small, warnings) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... ``` Workaround for #25338 -
This is helpful when making changes to base and must update the javascript and i386 base exports files.
-
When linking a module with a large dependency footprint too much of the object files were forced during linking. This lead to a large amount of memory taken up by thunks which would never be forced On the PartialDownsweep test this halves the memory required (from 25G to 13G). Towards #25324 ------------------------- Metric Increase: size_hello_obj ------------------------- -
-
Fixes the following error when building GHC on alpha-linux: rts/posix/Signals.c: In function ‘initDefaultHandlers’: rts/posix/Signals.c:709:5: error: error: implicit declaration of function ‘ieee_set_fp_control’ [-Wimplicit-function-declaration] 709 | ieee_set_fp_control(0); | ^~~~~~~~~~~~~~~~~~~ | 709 | ieee_set_fp_control(0); | -
We never populate it, so remove it.
-
- Oct 06, 2024
-
-
Fixes #25243
-
Solves documentaion issue #25084.
-
This reuses the upsweep step's infrastructure to process batches of modules in parallel. I benchmarked this by running `ghc -M` on two sets of 10,000 modules; one with a linear dependency chain and the other with a binary tree. Comparing different values for the number of modules per thread suggested an optimum at `length targets `div` (n_cap * 2)`, with results similar to this one (6 cores, 12 threads): ``` Benchmark 1: linear 1 jobs Time (mean ± σ): 1.775 s ± 0.026 s [User: 1.377 s, System: 0.399 s] Range (min … max): 1.757 s … 1.793 s 2 runs Benchmark 2: linear 6 jobs Time (mean ± σ): 876.2 ms ± 20.9 ms [User: 1833.2 ms, System: 518.6 ms] Range (min … max): 856.2 ms … 898.0 ms 3 runs Benchmark 3: linear 12 jobs Time (mean ± σ): 793.5 ms ± 23.2 ms [User: 2318.9 ms, System: 718.6 ms] Range (min … max): 771.9 ms … 818.0 ms 3 runs ``` Results don't differ much when the batch size is reduced to a quarter of that, but there's significant thread scheduling overhead for a size of 1: ``` Benchmark 1: linear 1 jobs Time (mean ± σ): 2.611 s ± 0.029 s [User: 2.851 s, System: 0.783 s] Range (min … max): 2.591 s … 2.632 s 2 runs Benchmark 2: linear 6 jobs Time (mean ± σ): 1.189 s ± 0.007 s [User: 2.707 s, System: 1.103 s] Range (min … max): 1.184 s … 1.194 s 2 runs Benchmark 3: linear 12 jobs Time (mean ± σ): 1.097 s ± 0.006 s [User: 2.938 s, System: 1.300 s] Range (min … max): 1.093 s … 1.101 s 2 runs ``` Larger batches also slightly worsen performance.
-
Cheng Shao authored
This commit fixes link-time unresolved symbol errors for sem_open etc on wasm, by making runWorkerLimit always behave single-threaded. This avoids introducing the jobserver logic into the final wasm module and thus avoids referencing the posix semaphore symbols.
-
- Oct 05, 2024
-
-
Implementing the final phase of CLC proposal https://github.com/haskell/core-libraries-committee/issues/86
-
Fixes #25330
-
- Oct 04, 2024
-
-
-
Basic changes: * Change `catch` function to propagate exceptions using the WhileHandling mechanism. * Introduce `catchNoPropagate`, which does the same as before, but passes an exception which can be rethrown. * Introduce `rethrowIO` combinator, which rethrows an exception with a context and doesn't add a new backtrace. * Introduce `tryWithContext` for a variant of `try` which can rethrow the exception with it's original context. * onException is modified to rethrow the original error rather than creating a new callstack. * Functions which rethrow in GHC.Internal.IO.Handle.FD, GHC.Internal.IO.Handle.Internals, GHC.Internal.IO.Handle.Text, and GHC.Internal.System.IO.Error are modified to not add a new callstack. Implements CLC proposal#202 <https://github.com/haskell/core-libraries-committee/issues/202>
-
Fixes #25235
-
As proposed in core-libraries-committee#275.
-
