- Mar 24, 2021
-
-
-
Ben Gamari authored
-
Ben Gamari authored
-
- Mar 23, 2021
-
-
The loader state was stored into HscEnv. As we need to have two interpreters and one loader state per interpreter in #14335, it's natural to make the loader state a field of the Interp type. As a side effect, many functions now only require a Interp parameter instead of HscEnv. Sadly we can't fully free GHC.Linker.Loader of HscEnv yet because the loader is initialised lazily from the HscEnv the first time it is used. This is left as future work. HscEnv may not contain an Interp value (i.e. hsc_interp :: Maybe Interp). So a side effect of the previous side effect is that callers of the modified functions now have to provide an Interp. It is satisfying as it pushes upstream the handling of the case where HscEnv doesn't contain an Interpreter. It is better than raising a panic (less partial functions, "parse, don't validate", etc.).
-
Previously `pathstat` relied on msvcrt's `stat` implementation, which was not long-path-aware. It should rather be defined in terms of the `stat` implementation provided by `utils/fs`. Fixes #19541.
-
-
-
- Mar 22, 2021
-
-
Part of #18202 ------------------------- Metric Decrease: T12707 T3294 -------------------------
-
This Note says it all: Note [Skip type holes rapidly] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppose we have module with a /lot/ of partial type signatures, and we compile it while suppressing partial-type-signature warnings. Then we don't want to spend ages constructing error messages and lists of relevant bindings that we never display! This happened in #14766, in which partial type signatures in a Happy-generated parser cause a huge increase in compile time. The function ignoreThisHole short-circuits the error/warning generation machinery, in cases where it is definitely going to be a no-op. It makes a pretty big difference on the Sigs.hs example in #14766: Compile-time allocation GHC 8.10 5.6G Before this patch 937G With this patch 4.7G Yes, that's more than two orders of magnitude!
-
-
As noted in #19540, a number of users within and outside of GHC rely on unsafeCoerceUnlifted to work around the fact that this was missing
-
Moritz Angermann authored
-
Moritz Angermann authored
For now only the apple flavoured llvm knows vortex, as we build against other toolchains, lets stay with generic for now.
-
Moritz Angermann authored
-
Moritz Angermann authored
This is a set of forward ports (cherry-picks) from 8.10 - a7d22795 [ci] Add support for building on aarch64-darwin - 5109e87e [testlib/driver] denoise - 307d3494 [ci] default value for CONFIGURE_ARGS - 10a18cb4 [testsuite] mark ghci056 as fragile - 16c13d5a [ci] Default value for MAKE_ARGS - ab571457 [ci/build] Copy config.sub around - 251892b9 [ci/darwin] bump nixpkgs rev - 5a6c36ec [testsuite/darwin] fix conc059 - aae95ef0 [ci] add timing info - 3592d110 [Aarch64] No div-by-zero; disable test. - 57671071 [Darwin] mark stdc++ tests as broken - 33c4d497 [testsuite] filter out superfluous dylib warnings - 4bea83af [ci/nix-shell] Add Foundation and Security - 63455300 [testsuite/json2] Fix failure with LLVM backends - c3944bc8 [ci/nix-shell] [Darwin] Stop the ld warnings about libiconv. - b821fcc7 [testsuite] static001 is not broken anymore. - f7062e1b [testsuite/arm64] fix section_alignment - 820b0766 [darwin] stop the DYLD_LIBRARY_PATH madness - 07b1af03 [ci/nix-shell] uniquify NIX_LDFLAGS{_FOR_TARGET} As well as a few additional fixups needed to make this block compile: - Fixup all.T - Set CROSS_TARGET, BROKEN_TESTS, XZ, RUNTEST_ARGS, default value. - [ci] shell.nix bump happy
-
- Mar 21, 2021
-
-
The `extendTyVarEnvFVRn` function does the exact same thing as `bindLocalNamesFV`. I see no meaningful distinction between the two functions, so let's just remove the former (which is only used in a handful of places) in favor of the latter. Historical note: `extendTyVarEnvFVRn` and `bindLocalNamesFV` used to be distinct functions, but their implementations were synchronized in 2004 as a part of commit 20e39e0e.
-
- Mar 20, 2021
-
-
Ryan Scott authored
This requires bumping the `exceptions` and `text` submodules to bring in commits that bump their respective upper version bounds on `template-haskell`. Fixes #19083.
-
Ryan Scott authored
-
(cherry picked from commit 4f334120c8e9cc4aefcbf11d99f169f648af9fde)
-
Ben Gamari authored
Currently we are suffering from issues that appear to be caused by non-hermetic builds. Try avoiding this by setting `GIT_STRATEGY` to `clone`.
-
-
-
-
It seems like I imported "GHC.Types ()" thinking that it would transitively import GHC.Num.Integer when I wrote that module; but it doesn't. This led to build failures. See https://mail.haskell.org/pipermail/ghc-devs/2021-March/019641.html
-
All credit to @hsyl20, who in ghc/ghc!4717 (comment 338560) figured out this was a problem. To fix this, we use casts in addition to the shrinking and suffixing that is already done. It might make for more verbose code, I don't think that matters too much. In the future, perhaps some of the shrinking and suffixing can be removed for being redundant. That proved less trivial than it sounds, so this wasn't done at this time. Progress towards #19026 Metric Increase: T12707 T13379 Co-authored-by:
Sylvain Henry <hsyl20@gmail.com>
-
It's quite backend-dependent whether we will actually handle that case right, so let's just always do this as a precaution. In particular, once we replace the native primops used here with the new sized primops, the 16-bit ones on x86 will begin to use 16-bit sized instructions where they didn't before. Though I'm not sure of any arch which has 8-bit scalar instructions, I also did those for consistency. Plus, there are *vector* 8-bit ops in the wild, so if we ever got into autovectorization or something maybe it's prudent to put this here as a reminder not to forget about catching overflows. Progress towards #19026
-
As #19522 points out, we did not account for visible type application when trying to reject naked levity-polymorphic functions that have no binding. This patch tidies up the code, and fixes the bug too.
-
-
While fixing #19232, it became increasingly clear that the vestigial hack described in `Note [Optimistic field binder CPR]` is complicated and causes reboxing. Rather than make the hack worse, this patch gets rid of it completely in favor of giving deeply unboxed parameters the Nested CPR property. Example: ```hs f :: (Int, Int) -> Int f p = case p of (x, y) | x == y = x | otherwise = y ``` Based on `p`'s `idDemandInfo` `1P(1P(L),1P(L))`, we can see that both fields of `p` will be available unboxed. As a result, we give `p` the nested CPR property `1(1,1)`. When analysing the `case`, the field CPRs are transferred to the binders `x` and `y`, respectively, so that we ultimately give `f` the CPR property. I took the liberty to do a bit of refactoring: - I renamed `CprResult` ("Constructed product result result") to plain `Cpr`. - I Introduced `FlatConCpr` in addition to (now nested) `ConCpr` and and according pattern synonym that rewrites flat `ConCpr` to `FlatConCpr`s, purely for compiler perf reasons. - Similarly for performance reasons, we now store binders with a Top signature in a separate `IntSet`, see `Note [Efficient Top sigs in SigEnv]`. - I moved a bit of stuff around in `GHC.Core.Opt.WorkWrap.Utils` and introduced `UnboxingDecision` to replace the `Maybe DataConPatContext` type we used to return from `wantToUnbox`. - Since the `Outputable Cpr` instance changed anyway, I removed the leading `m` which we used to emit for `ConCpr`. It's just noise, especially now that we may output nested CPRs. Fixes #19398. -
This commit reduces allocations by the simplifier by 3% for the Cabal test at -O2. We do this by making a few select fields, bindings and arguments strict which reduces allocations for the simplifier by around 3% in total for the Cabal test. Which is about 2% fewer allocations in total at -O2. ------------------------- Metric Decrease: T18698a T18698b T9233 T9675 T9872a T9872b T9872c T9872d T10421 T12425 T13253 T5321FD T9961 ------------------------- -
tuples and sums. fixes #1257
-
Metric Increase: MultiLayerModules -
-
The 'id' type is now determined by the pass, using the XTickishId type family.
-
GHCi needs to know the types of all breakpoints, but it's not possible to get the exprType of any expression in STG. This is preparation for the upcoming change to make GHCi bytecode from STG instead of Core.
-
In the `comments` and `literals` tests, since they contain file paths.
-
Previously we would use `writeFile` to write the intermediate files to check for round-tripping. However, this will open the output handle as a text handle, which on Windows will change line endings. Avoid this by opening as binary. Explicitly use utf8 encoding. This is for tests only, do not need to worry about user compatibility.
-
Metric Increase: T10370 parsing001 Updates haddock submodule -
The MR introducing the API Annotations, !2418 is huge. Conceptually it is two parts, the one deals with introducing the new types to be used for annotations, and outlining how they will be used. This is a small change, localised to compiler/GHC/Parser/Annotation.hs and is contained in this commit. The follow-up, larger commit deals with mechanically working this through the entire AST and updating all the parts affected by it. It is being split so the part that needs good review feedback can be seen in isolation, prior to the rest coming in.
-
Current documentation for the `Ord` typeclass is inconsistent. It simultaneously mentions that: > The 'Ord' class is used for totally ordered datatypes. And: > The Haskell Report defines no laws for 'Ord'. However, '<=' is > customarily expected to implement a non-strict partial order […] The Haskell report (both 98 and 2010 versions) mentions total ordering, which implicitly does define laws. Moreover, `compare :: Ord a => a -> a -> Ordering` and `data Ordering = LT | EQ | GT` imply that the order is indeed total (there is no way to say that two elements are not comparable). This MR fixes the Haddock comment, and adds a comparability law to the list of suggested properties.
-
