summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Move aarch64-linux-llvm to nightlywip/angerman/de-elongate-pipelineMoritz Angermann2021-07-011-0/+1
| | | | | | 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.
* Revert "Move validate-x86_64-linux-deb9-hadrian back to quick-build"Moritz Angermann2021-07-011-1/+1
| | | | This reverts commit a0622459f1d9a7068e81b8a707ffc63e153444f8.
* [ci] Enable T6132 across all targetsMoritz Angermann2021-07-011-8/+1
| | | | We should have fixed clangs mess now.
* [Parser: Lexer] Fix !6132Moritz Angermann2021-07-011-1/+2
| | | | clang's cpp injects spaces prior to #!/.
* [ci] Separate llvm and NCG test metrics for aarch64-linuxMoritz Angermann2021-07-011-0/+3
|
* [ci] don't allow aarch64-linux (ncg) to failMoritz Angermann2021-07-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | by accepting the current state of metrics (and the NCG is new, so this seems prudent to do), we can require aarch64-linux (ncg) to build without permitting failure. Metric Increase: T13035 T13719 T14697 T1969 T9203 T9872a T9872b T9872c T9872d T9961 WWRec haddock.Cabal haddock.base parsing001
* Unify remaining GHCi prompt exampleEmily Martins2021-07-011-1/+1
| | | | Signed-off-by: Emily Martins <emily.flakeheart@gmail.com>
* Unify primary and secondary GHCi promptEmily Martins2021-07-012-16/+16
| | | | | | | Fixes #20042 Signed-off-by: Emily Martins <emily.flakeheart@gmail.com> Signed-off-by: Hécate Moonlight <hecate@glitchbra.in>
* Dynflags: introduce DiagOptsSylvain Henry2021-07-0129-209/+296
| | | | | | | | | | | | | | | | | | | | | | Use DiagOpts for diagnostic options instead of directly querying DynFlags (#17957). Surprising performance improvements on CI: T4801(normal) ghc/alloc 313236344.0 306515216.0 -2.1% GOOD T9961(normal) ghc/alloc 384502736.0 380584384.0 -1.0% GOOD ManyAlternatives(normal) ghc/alloc 797356128.0 786644928.0 -1.3% ManyConstructors(normal) ghc/alloc 4389732432.0 4317740880.0 -1.6% T783(normal) ghc/alloc 408142680.0 402812176.0 -1.3% Metric Decrease: T4801 T9961 T783 ManyAlternatives ManyConstructors Bump haddock submodule
* Remove useless .hs-bootSylvain Henry2021-07-0118-41/+2
|
* Make withException use SDocContext instead of DynFlagsSylvain Henry2021-07-014-9/+14
|
* Add testcase for #19460Roland Senn2021-07-014-0/+15
| | | | Avoid an other regression.
* ci: Don't allow aarch64-darwin to failMatthew Pickering2021-06-291-3/+0
| | | | Part way to #20013
* Use HsExpansion for overloaded list patternssheaf2021-06-2922-247/+430
| | | | Fixes #14380, #19997
* Demand: Better representation (#19050)Sebastian Graf2021-06-292-186/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In #19050, we identified several ways in which we could make more illegal states irrepresentable. This patch introduces a few representation changes around `Demand` and `Card` with a better and earlier-failing API exported through pattern synonyms. Specifically, 1. The old enum definition of `Card` led to severely bloated code of operations on it. I switched to a bit vector representation; much nicer overall IMO. See Note [Bit vector representation for Card]. Most of the gripes with the old representation were related to where which kind of `Card` was allowed and the fact that it doesn't make sense for an absent or bottoming demand to carry a `SubDemand` that describes an evaluation context that is never realised. 2. So I refactored the `Demand` representation so that it has two new data constructors for `AbsDmd` and `BotDmd`. The old `(:*)` data constructor becomes a pattern synonym which expands absent demands as needed, so that it still forms a complete match and a versatile builder. The new `Demand` data constructor now carries a `CardNonAbs` and only occurs in a very limited number of internal call sites. 3. Wherever a full-blown `Card` might end up in a `CardNonAbs` field (like that of `D` or `Call`), I assert the consistency. When the smart builder of `(:*)` is called with an absent `Card`, I assert that the `SubDemand` is the same that we would expand to in the matcher. 4. `Poly` now takes a `CardNonOnce` and encodes the previously noticed invariant that we never produce `Poly C_11` or `Poly C_01`. I made sure that we never construct a `Poly` with `C_11` or `C_01`. Fixes #19050. We lose a tiny bit of anal perf overall, probably because the new `Demand` definition can't be unboxed. The biggest loser is WWRec, where allocations go from 16MB to 26MB in DmdAnal, making up for a total increase of (merely) 1.6%. It's all within acceptance thresholds. There are even two ghc/alloc metric decreases. T11545 decreases by *67%*! Metric Decrease: T11545 T18304
* Fix type and strictness signature of forkOn#Ryan Scott2021-06-282-2/+6
| | | | | | This is a follow-up to #19992, which fixes the type and strictness signature for `fork#`. The `forkOn#` primop also needs analogous changes, which this patch accomplishes.
* Try to simplify zoo of functions in `Tc.Utils.Monad`Alfredo Di Napoli2021-06-2848-788/+1259
| | | | | | | | | | | This commit tries to untangle the zoo of diagnostic-related functions in `Tc.Utils.Monad` so that we can have the interfaces mentions only `TcRnMessage`s while we push the creation of these messages upstream. It also ports TcRnMessage diagnostics to use the new API, in particular this commit switch to use TcRnMessage in the external interfaces of the diagnostic functions, and port the old SDoc to be wrapped into TcRnUnknownMessage.
* Update docs for change in parsing behaviour of infix operators like in GHC 9Zubin Duggal2021-06-281-2/+8
|
* Fix libffi on PowerPCPeter Trommler2021-06-284-20/+4
| | | | | | | | | Update submodule libffi-tarballs to upstream commit 4f9e20a. Remove C compiler flags that suppress warnings in the RTS. Those warnings have been fixed by libffi upstream. Fixes #19885
* Revert "Make reallyUnsafePtrEquality# levity-polymorphic"Matthew Pickering2021-06-279-76/+1
| | | | | | | | | | | | | | | | | | | | | | | This reverts commit d1f59540e8b7be96b55ab4b286539a70bc75416c. This commit breaks the build of unordered-containers ``` [3 of 9] Compiling Data.HashMap.Internal.Array ( Data/HashMap/Internal/Array.hs, dist/build/Data/HashMap/Internal/Array.o, dist/build/Data/HashMap/Internal/Array.dyn_o ) *** Parser [Data.HashMap.Internal.Array]: Parser [Data.HashMap.Internal.Array]: alloc=21043544 time=13.621 *** Renamer/typechecker [Data.HashMap.Internal.Array]: Renamer/typechecker [Data.HashMap.Internal.Array]: alloc=151218672 time=187.083 *** Desugar [Data.HashMap.Internal.Array]: ghc: panic! (the 'impossible' happened) GHC version 9.3.20210625: expectJust splitFunTy CallStack (from HasCallStack): error, called at compiler/GHC/Data/Maybe.hs:68:27 in ghc:GHC.Data.Maybe expectJust, called at compiler/GHC/Core/Type.hs:1247:14 in ghc:GHC.Core.Type ``` Revert containers submodule update
* testsuite: Widen acceptance window of T12545 (#19414)Sebastian Graf2021-06-272-4/+44
| | | | | | | | | | | | | | | | | | In a sequel of #19414, I wrote a script that measures min and max allocation bounds of T12545 based on randomly modifying -dunique-increment. I got a spread of as much as 4.8%. But instead of widening the acceptance window further (to 5%), I committed the script as part of this commit, so that false positive increases can easily be diagnosed by comparing min and max bounds to HEAD. Indeed, for !5814 we have seen T12545 go from -0.3% to 3.3% after a rebase. I made sure that the min and max bounds actually stayed the same. In the future, this kind of check can very easily be done in a matter of a minute. Maybe we should increase the acceptance threshold if we need to check often (leave a comment on #19414 if you had to check), but I've not been bitten by it for half a year, which seems OK. Metric Increase: T12545
* Inliner: Regard LitRubbish as TrivArg and not ConLikeSebastian Graf2021-06-272-2/+7
| | | | | | | | | | | | | | | | | | | | | | Part of fixing #19766 required the emission of `LitRubbish` as absent filler in places where we used `absentError` before. In WWRec we have the situation that such bindings occur in the argument to functions. With `LitRubbish` we inlined those functions, because 1. The absent binding was regarded as ConLike. So I fixed `exprIsHNFLike` to respond `False` to `LitRubbish`. 2. The other source of inlining was that after inlining such an absent binding, `LitRubbish` itself was regarded `ValueArg` by `interestingArg`, leading to more inlining. It now responds `TrivArg` to `LitRubbish`. Fixes #20035. There's one slight 1.6% ghc/alloc regression left in T15164 that is due to an additional specialisation `$s$cget`. I've no idea why that happens; the Core output before is identical and has the call site that we specialise for. Metric Decrease: WWRec
* Add regression test for #17819Sebastian Graf2021-06-273-0/+331
| | | | The only item left in #17819. Fixes #17819.
* WorkWrap: Make mkWWstr and mkWWcpr generate fewer let bindingsSebastian Graf2021-06-273-79/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5814#note_355144, Simon noted that `mkWWstr` and `mkWWcpr` could generate fewer let bindings and be implemented less indirectly by returning the rebuilt expressions directly, e.g. instead of ``` f :: (Int, Int) -> Int f (x, y) = x+y ==> f :: (Int, Int) -> Int f p = case p of (x, y) -> case x of I# x' -> case y of I# y' -> case $wf x' y' of r' -> let r = I# r' -- immediately returned in r f :: Int# -> Int# -> Int# $wf x' y' = let x = I# x' in -- only used in p let y = I# y' in -- only used in p let p = (x, y) in -- only used in the App below case (\(x,y) -> x+y) p of I# r' -> r' ``` we know generate ``` f :: (Int, Int) -> Int f p = case p of (x, y) -> case x of I# x' -> case y of I# y' -> case $wf x' y' of r' -> I# r' -- 1 fewer let f :: Int# -> Int# -> Int# $wf x' y' = case (\(x,y) -> x+y) (I# x, I# y) of I# r' -> -- 3 fewer lets r' ``` Which is much nicer and makes it easier to comprehend the output of worker-wrapper pre-Simplification as well as puts less strain on the Simplifier. I had to drop support for #18983, but we found that it's broken anyway. Simon is working on a patch that provides a bit more justification.
* WorkWrap: Remove mkWWargs (#19874)Sebastian Graf2021-06-2716-248/+239
| | | | | | | | | | | | | | | | | | | | `mkWWargs`'s job was pushing casts inwards and doing eta expansion to match the arity with the number of argument demands we w/w for. Nowadays, we use the Simplifier to eta expand to arity. In fact, in recent years we have even seen the eta expansion done by w/w as harmful, see Note [Don't eta expand in w/w]. If a function hasn't enough manifest lambdas, don't w/w it! What purpose does `mkWWargs` serve in this world? Not a great one, it turns out! I could remove it by pulling some important bits, notably Note [Freshen WW arguments] and Note [Join points and beta-redexes]. Result: We reuse the freshened binder names of the wrapper in the worker where possible (see testuite changes), much nicer! In order to avoid scoping errors due to lambda-bound unfoldings in worker arguments, we zap those unfoldings now. In doing so, we fix #19766. Fixes #19874.
* Simplifier: Do Cast W/W for INLINE strong loop-breakersSebastian Graf2021-06-2714-59/+68
| | | | | | | | | | | | | | | | | | | | Strong loop-breakers never inline, INLINE pragma or not. Hence they should be treated as if there was no INLINE pragma on them. Also not doing Cast W/W for INLINE strong loop-breakers will trip up Strictness W/W, because it treats them as if there was no INLINE pragma. Subsequently, that will lead to a panic once Strictness W/W will no longer do eta-expansion, as we discovered while implementing !5814. I also renamed to `unfoldingInfo` to `realUnfoldingInfo` and redefined `unfoldingInfo` to zap the unfolding it returns in case of a strong loop-breaker. Now the naming and semantics is symmetrical to `idUnfolding`/`realIdUnfolding`. Now there was no more reason for `hasInlineUnfolding` to operate on `Id`, because the zapping of strong loop-breaker unfoldings moved from `idUnfolding` to `unfoldingInfo`, so I refactored it to take `IdInfo` and call it both from the Simplifier and WorkWrap, making it utterly clear that both checks are equivalent.
* Tc: Allow Typeable in quantified constraintsJakob Brünker2021-06-273-0/+19
| | | | | | | | | Previously, when using Typeable in a quantified constraint, GHC would complain that user-specified instances of Typeable aren't allowed. This was because checking for SigmaCtxt was missing from a check for whether an instance head is a hand-written binding. Fixes #20033
* user-guide: Improve documentation of NumDecimalsZubin Duggal2021-06-271-6/+16
|
* Re-export UnliftedRep and UnliftedType from GHC.Extssheaf2021-06-261-1/+2
|
* rts: Eliminate redundant branchGHC GitLab CI2021-06-261-3/+1
| | | | | | Previously we branched unnecessarily on IF_NONMOVING_WRITE_BARRIER_ENABLED on every trip through the array barrier push loop.
* codeGen: Fix header size for array write barriersGHC GitLab CI2021-06-261-3/+3
| | | | | | | | | Previously the code generator's logic for invoking the nonmoving write barrier was inconsistent with the write barrier itself. Namely, the code generator treated the header size argument as being in words whereas the barrier expected bytes. This was the cause of #19715. Fixes #19715.
* driver: Add implicit package dependencies for template-haskell packageMatthew Pickering2021-06-253-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | When TemplateHaskellQuotes is enabled, we also generate programs which mention symbols from the template-haskell module. So that package is added conditionally if the extension is turned on. We should really do the same for other wired-in packages: * base * ghc-bignum * ghc-prim * rts When we link an executable, we must also link against these libraries. In accordance with every other package, these dependencies should be added into the direct dependencies for a module automatically and end up in the interface file to record the fact the object file was created by linking against these packages. Unfortunately it is not so easy to work out when symbols from each of these libraries ends up in the generated program. You might think that `base` would always be used but the `ghc-prim` package doesn't depend on `base`, so you have to be a bit careful and this futher enhancement is left to a future patch.
* Suggest similar names when reporting types in terms (#19978)Vladislav Zavialov2021-06-255-27/+83
| | | | This fixes an error message regression.
* Add regression test for #19921Zubin Duggal2021-06-253-0/+39
|
* driver: Add test for T14923Matthew Pickering2021-06-253-0/+27
|
* driver: Add test for #17481Matthew Pickering2021-06-253-0/+37
| | | | | | Fixed in 25977ab542a30df4ae71d9699d015bcdd1ab7cfb Fixes #17481
* ghci: Add test for #18330Matthew Pickering2021-06-255-0/+23
| | | | | | This test was fixed by 25977ab542a30df4ae71d9699d015bcdd1ab7cfb Fixes #18330
* Make reallyUnsafePtrEquality# levity-polymorphicsheaf2021-06-259-1/+76
| | | | fixes #17126, updates containers submodule
* fix sdist for base libraryLuite Stegeman2021-06-241-2/+0
| | | | | config.sub and config.guess aren't used anymore, so they should be removed from the base.cabal file
* linker: Replace one missed usage of Opt_RPath with useXLinkerRPathMatthew Pickering2021-06-241-1/+1
| | | | Thanks to @wz1000 for spotting this oversight.
* [iserv] learn -wait cli flagMoritz Angermann2021-06-241-5/+18
| | | | | | Often times when attaching a debugger to iserv it's helpful to have iserv wait a few seconds for the debugger to attach. -wait can be passed via -opti-wait if needed.
* Update quantified_constraints.rstChristian Takle2021-06-241-2/+2
|
* Fixes around incomplete guards (#20023, #20024)Krzysztof Gogolewski2021-06-2411-36/+27
| | | | | | | | | | - Fix linearity error with incomplete MultiWayIf (#20023) - Fix partial pattern binding error message (#20024) - Remove obsolete test LinearPolyTest It tested the special typing rule for ($), which was removed during the implementation of Quick Look 97cff9190d3. - Fix ticket numbers in linear/*/all.T, they referred to linear types issue tracker
* There's no "errorWithCallStack", just use "error".Viktor Dukhovni2021-06-241-9/+8
| | | | | | | | There's no `errorWithCallStack`, only `errorWithStackTrace`, but the latter is now deprecated, since `error` now defaults to returning a stack strace. So rather than change this to the intended deprecated function we replace `errorWithCallStack` with `error` instead.
* cabal_test: Make output more like head.hackage outputMatthew Pickering2021-06-241-2/+4
| | | | This helps with the import of the results into the performance database.
* CI: Fix the cabal_test job to compile the Distribution.Simple targetMatthew Pickering2021-06-241-1/+2
| | | | | | The "Cabal test" was previously testing the compilation of the very advanced Setup.hs file. Now we compile the whole library, as the test intended.
* [aarch64-macho] Fix off-by-one error in the linkerMoritz Angermann2021-06-241-1/+11
| | | | | | We need to be careful about the sign bit for BR26 relocation otherwise we end up encoding a large positive number and reading back a large negative number.
* EPA: Bringing over tests and updates from ghc-exactprintAlan Zimmerman2021-06-2432-463/+1269
|
* Fix desugaring with unboxed types (#19883)Krzysztof Gogolewski2021-06-243-1/+21
|
* rts: move xxxHash out of the user namespaceTamar Christina2021-06-244-7/+25
|
View Lorry Controller Status