- 13 Jul, 2021 3 commits
-
-
-
-
Add some more tests, update documentation. Responses to comments on PR. Add a note about why sums and products are handled so differently by dataConArgUnpack. Add a test demonstrating performance difference between unpacked and standard sums Add a test to check that unboxed sums appear in the core output for a program involving an UNPACK pragma on a sum-typed field. Some small refactors in response to Simon's comments skip unpacking newtypes that aren't reduced by topNormaliseType. fix CoreAlt change.
-
- 10 Jul, 2021 2 commits
-
-
Hopefully fixes the flaky CI failures we have seen recently. Co-authored-by:Moritz Angerman <moritz.angermann@gmail.com>
-
sheaf authored
- fixes #18149 and #14765 dsWhenNoErrs now returns "runtimeError @ty" when disallowed representation polymorphism is detected, where ty is the type of the result CoreExpr. "ty" is passed as an additional argument to dsWhenNoErrs, and is used only in the case of such an error. The calls to dsWhenNoErrs must now compute the type of the CoreExpr they are trying to build, so that an error of the right type can be used in case of a representation polymorphism failure.
-
- 09 Jul, 2021 15 commits
-
-
getProgName was used to append the name of the program (e.g. "ghc") to printed error messages in the Show instance of GhcException. It doesn't belong here as GHCi and GHC API users may want to override this behavior by setting a different error handler. So we now call it in the defaultErrorHandler instead.
-
-
-
-
-
-
-
-
-
-
-
-
This commit adds the TcRnShadowedName to the TcRnMessage type and it uses it in GHC.Rename.Utils.
-
-
-
- 08 Jul, 2021 1 commit
-
-
Alfredo Di Napoli authored
This commit renames the `getErrorMessages` and `getMessages` function in the parser code to `getPsErrorMessages` and `getPsMessages`, to avoid import conflicts, as we have already `getErrorMessages` and `getMessages` defined in `GHC.Types.Error`. Fixes #19920. Update haddock submodule
-
- 07 Jul, 2021 2 commits
-
-
This test has worked since 8.10.2 at least but was recently broken and is now working again after this patch. Closes #12983
-
This patch converts the runPipeline function to be implemented in terms of a free monad rather than the previous CompPipeline. The advantages of this are three-fold: 1. Different parts of the pipeline can return different results, the limits of runPipeline were being pushed already by !5555, this opens up futher fine-grainedism of the pipeline. 2. The same mechanism can be extended to build-plan at the module level so the whole build plan can be expressed in terms of one computation which can then be treated uniformly. 3. The pipeline monad can now be interpreted in different ways, for example, you may want to interpret the `TPhase` action into the monad for your own build system (such as shake). That bit will probably require a bit more work, but this is a step in the right directin. There are a few more modules containing useful functions for interacting with the pipelines. * GHC.Driver.Pipeline: Functions for building pipelines at a high-level * GHC.Driver.Pipeline.Execute: Functions for providing the default interpretation of TPhase, in terms of normal IO. * GHC.Driver.Pipeline.Phases: The home for TPhase, the typed phase data type which dictates what the phases are. * GHC.Driver.Pipeline.Monad: Definitions to do with the TPipelineClass and MonadUse class. Hooks consumers may notice the type of the `phaseHook` has got slightly more restrictive, you can now no longer control the continuation of the pipeline by returning the next phase to execute but only override individual phases. If this is a problem then please open an issue and we will work out a solution. ------------------------- Metric Decrease: T4029 -------------------------
-
- 06 Jul, 2021 6 commits
-
-
Andreas Klebinger authoredWhen arguments are 8 *or 16* bits wide, then truncate before/after and use the 32bit operation.
-
-
-
'-x c++' was found to be required on Darwin Clang 11 and 12. '-std=c++' was found to be needed on Clang 12 but not 11.
-
-
System.Environment.getExecutablePath has some problems: - Some system-specific implementations throw an exception in some scenarios, e.g. when the executable file has been deleted - The Linux implementation succeeds but returns an invalid FilePath when the file has been deleted. - The fallback implementation returns argv[0] which is not necessarily an absolute path, and is subject to manipulation. - The documentation does not explain any of this. Breaking the getExecutablePath API or changing its behaviour is not an appealing direction. So we will provide a new API. There are two facets to the problem of querying the executable path: 1. Does the platform provide a reliable way to do it? This is statically known. 2. If so, is there a valid answer, and what is it? This may vary, even over the runtime of a single process. Accordingly, the type of the new mechanism is: Maybe (IO (Maybe FilePath)) This commit implements this mechanism, defining the query action for FreeBSD, Linux, macOS and Windows. Fixes: #10957 Fixes: #12377
-
- 03 Jul, 2021 2 commits
-
-
In #20070, we noticed that `findRhsArity` copes badly with shadowing. A simple function like `g_123 x_123 = x_123`, where the labmda binder shadows, already regressed badly. Indeed, the whole `arityType` function wasn't thinking about shadowing *at all*. I rectified that and established the invariant that `ae_join` and `am_sigs` should always be disjoint. That entails deleting bindings from `ae_join` whenever we add something to `am_sigs` and vice versa, which would otherwise be a bug in the making. That *should* fix (but I don't want to close it) #20070.
-
fixes #19628
-
- 02 Jul, 2021 5 commits
-
-
This job takes by far the longest time on its own, we now have a NCG. Once we have fast aarch64 machines, we can consider putting this one back.
-
This reverts commit a0622459.
-
-
Fix #20066
-
I discovered that GHC.Core.Unify.bindTv was getting arity 2, rather than 3, in one of my builds. In HEAD it does get the right arity, but only because CallArity (just) manages to spot it. In my situation it (just) failed to discover this. Best to make it robust, which this patch does. See Note [INLINE pragmas and (>>)] in GHC.Utils.Monad. There a bunch of other modules that probably should have the same treatment: GHC.CmmToAsm.Reg.Linear.State GHC.Tc.Solver.Monad GHC.Tc.Solver.Rewrite GHC.Utils.Monad.State.Lazy GHC.Utils.Monad.State.Strict but doing so is not part of this patch
-
- 01 Jul, 2021 4 commits
-
-
The test case `print036` was marked `broken` by #9046. Issue #9046 is a duplicate of #12449. However the test case `T12449` contains several test that are similar to those in `print036`. Hence test case `print036` is redundant and can be deleted.
-
-
We should have fixed clangs mess now.
-
clang's cpp injects spaces prior to #!/.
-
