| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
There was some confusion about whether FUN/TYPE/One/Many should be
BuiltInSyntax or UserSyntax. The answer is certainly UserSyntax as
BuiltInSyntax is for things which are directly constructed by the parser
rather than going through normal renaming channels.
I fixed all the obviously wrong places I could find and added a test for
the original bug which was caused by this (#21752)
Fixes #21752 #20695 #18302
|
|
|
|
|
| |
This MR just adds some documentation about why casts
destroy join points, following #21716.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not exist)
before the change `make install` was failing as:
```
"mv" "/<<NIX>>/ghc-9.3.20220406/lib/ghc-9.5.20220625/bin/ghc-stage2" "/<<NIX>>/ghc-9.3.20220406/lib/ghc-9.5.20220625/bin/ghc"
make[1]: *** No rule to make target 'mk/system-cxx-std-lib-1.0.conf.install', needed by 'install_packages'. Stop.
```
I think it's a recent regression caused by 0ef249aa where `system-cxx-std-lib-1.0.conf`
is created (somewhat manually), but not the .install varianlt of it.
The fix is to consistently use `mk/system-cxx-std-lib-1.0.conf` everywhere.
Closes: https://gitlab.haskell.org/ghc/ghc/-/issues/21784
|
|
|
|
| |
Evidently fields may not come after sections in a cabal file.
|
| |
|
|
|
|
|
|
|
|
| |
The AArch64/Darwin ABI requires that function arguments narrower
than 32-bits must be sign-extended by the caller. We neglected to
do this, resulting in #20735.
Fixes #20735.
|
|
|
|
| |
Previously there were very long, hard to parse lines. Fix this.
|
|
|
|
|
|
|
|
| |
Previously -ddump-llvm would change the backend used, which contrasts
with all other dump flags. This is quite surprising and cost me quite
a bit of time. Dump flags should not change compiler behavior.
Fixes #21776.
|
|
|
|
|
|
|
| |
Apple's AArch64 ABI requires that the caller sign-extend small integer
arguments. Set platformCConvNeedsExtension to reflect this fact.
Fixes #21773.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Noticed missing target directory dependency as a build failure in
`make --shuffle` mode (added in https://savannah.gnu.org/bugs/index.php?62100):
"cp" libraries/base/./GHC/Stack/CCS.hs-boot libraries/base/dist-install/build/GHC/Stack/CCS.hs-boot
cp: cannot create regular file 'libraries/base/dist-install/build/GHC/Stack/CCS.hs-boot': No such file or directory
libraries/haskeline/ghc.mk:4: libraries/haskeline/dist-install/build/.depend-v-p-dyn.haskell: No such file or directory
make[1]: *** [libraries/base/ghc.mk:4: libraries/base/dist-install/build/GHC/Stack/CCS.hs-boot] Error 1 shuffle=1656129254
make: *** [Makefile:128: all] Error 2 shuffle=1656129254
Note that `cp` complains about inability to create target file.
The change adds order-only dependency on a target directory (similar to
the rest of rules in that file).
The bug is lurking there since 2009 commit 34cc75e1a (`GHC new build
system megapatch`.) where upfront directory creation was never added to
`.hs-boot` files.
|
|
|
|
|
|
|
|
|
| |
Since 6be2c5a7e9187fc14d51e1ec32ca235143bb0d8b we would probe for LD
rather early in `configure`. However, it turns out that this breaks
`configure`'s `ld`-override logic, which assumes that `LD` was set by
the user and aborts.
Fixes #21778.
|
|
|
|
|
|
|
|
|
| |
Previously the output from test compilations used to determine whether,
e.g., profiling libraries are available was shown with verbosity
levels >= 2. However, the default level is 2, meaning that most users
were often spammed with confusing errors. Fix this by bumping the
verbosity threshold for this output to >=3.
Fixes #21760.
|
|
|
|
|
|
| |
This README had some quite out-of-date content about the build system so
I did a complete pass deleting old material. I also made the section
about flavours more prominent and mentioned flavour transformers.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Approved by CLC in https://github.com/haskell/core-libraries-committee/issues/9
Instances roughly follow
https://hackage.haskell.org/package/semigroupoids-5.3.7/docs/Data-Semigroup-Foldable-Class.html#t:Foldable1
but the API of `Foldable1` was expanded in comparison to `semigroupoids`.
Compatibility shim is available from https://github.com/phadej/foldable1 (to be released).
Closes #13573.
|
|
|
|
|
|
|
|
|
|
|
| |
OpenBSD will not ship any ghc packages on i386 starting with 7.2
release. This means there will not be a bootstrap compiler easily
available. The last available binaries are ghc-8.10.6 which is
already not supported as bootstrap for HEAD.
See here for more information:
https://marc.info/?l=openbsd-ports&m=165060700222580&w=2
|
|
|
|
|
|
|
| |
In case of a misspelled pragma, offer possible corrections as to what
the user could have meant.
Fixes: https://gitlab.haskell.org/ghc/ghc/-/issues/21589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to put OtherCon unfoldings on lambda binders of workers
and sometimes also join points/specializations with with the
assumption that since the wrapper would force these arguments
once we execute the RHS they would indeed be in WHNF.
This was wrong for reasons detailed in #21472. So now we purge
evaluated unfoldings from *all* lambda binders.
This fixes #21472, but at the cost of sometimes not using as efficient a
calling convention. It can also change inlining behaviour as some
occurances will no longer look like value arguments when they did
before.
As consequence we also change how we compute CBV information for
arguments slightly. We now *always* determine the CBV convention
for arguments during tidy. Earlier in the pipeline we merely mark
functions as candidates for having their arguments treated as CBV.
As before the process is described in the relevant notes:
Note [CBV Function Ids]
Note [Attaching CBV Marks to ids]
Note [Never put `OtherCon` unfoldigns on lambda binders]
-------------------------
Metric Decrease:
T12425
T13035
T18223
T18223
T18923
MultiLayerModulesTH_OneShot
Metric Increase:
WWRec
-------------------------
|
| |
|
| |
|
|
|
|
|
| |
Previously several tests' output were unnecessarily dependent on version
numbers, particularly of `base`. Fix this.
|
|
|
|
|
|
|
|
|
| |
To 0.9.0 and 4.17.0 respectively.
Bumps array, deepseq, directory, filepath, haskeline, hpc, parsec, stm,
terminfo, text, unix, haddock, and hsc2hs submodules.
(cherry picked from commit ba47b95122b7b336ce1cc00896a47b584ad24095)
|
|
|
|
|
|
| |
Allows the shake runner to build with 9.2.3 among other things.
Fixes #21772
|
|
|
|
|
| |
Downstream bug for reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261798
Relevant upstream issue: #15718
|
|
|
|
|
|
|
|
|
|
|
| |
For one by mistake I had been checking against the kind of runtime rep
instead of the boxity.
This uncovered another bug, namely that we tried to generate the
checking code before we had associated the function arguments with
a register, so this could never have worked to begin with.
This fixes #21729 and both of the above issues.
|
|
|
|
| |
Fixes #21697.
|
|
|
|
| |
CLC proposal: https://github.com/haskell/core-libraries-committee/issues/45
|
| |
|
|
|
|
|
|
|
| |
Previously we failed to reset pointers to various eventlog buffers to
NULL after freeing them. In principle we shouldn't look at them after
they are freed but nevertheless it is good practice to set them to a
well-defined value.
|
|
|
|
|
|
|
|
|
| |
In #21483 I had a discussion with Simon Marlow about the memory
retention behaviour of -Fd. I have just transcribed that conversation
here as it elucidates the potentially subtle assumptions which led to
the design of the memory retention behaviours of -Fd.
Fixes #21483
|
| |
|
|
|
|
|
| |
CLC discussion here:
https://github.com/haskell/core-libraries-committee/issues/58
|
| |
|
| |
|
|
|
|
| |
Happily, this has been fixed since 9.2.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-flocal-float-out-top-level CLI flags
These flags affect the behaviour of local let floating.
If `-flocal-float-out` is disabled (the default) then we disable all
local floating.
```
…(let x = let y = e in (a,b) in body)...
===>
…(let y = e; x = (a,b) in body)...
```
Further to this, top-level local floating can be disabled on it's own by
passing -fno-local-float-out-top-level.
```
x = let y = e in (a,b)
===>
y = e; x = (a,b)
```
Note that this is only about local floating, ie, floating two adjacent
lets past each other and doesn't say anything about the global floating
pass which is controlled by `-fno-float`.
Fixes #13663
|
|
|
|
|
|
| |
This reverts commit da5ff10503e683e2148c62e36f8fe2f819328862.
This was pushed directly without review.
|
| |
|
| |
|
|
|
|
| |
One more step towards the new design of EPA.
|
|
|
|
|
|
| |
We were attempting to boot a src-tarball which doesn't work as ./boot is
not included in the source tarball. This slipped through as the job is
only run on nightly.
|
|
|
|
|
|
| |
Fix ghc/ghc#21739
Squash fix ghc/ghc#21739
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main fix for #21667 is the new call to tcInstTypeBnders
in tcHsPartialSigType. It was really a simple omission before.
I also moved the decision about whether we need to apply the
Monomorphism Restriction, from `decideGeneralisationPlan` to
`tcPolyInfer`. That removes a flag from the InferGen constructor,
which is good.
But more importantly, it allows the new function,
checkMonomorphismRestriction
called from `tcPolyInfer`, to "see" the `Types` involved rather than
the `HsTypes`. And that in turn matters because we invoke the MR for
partial signatures if none of the partial signatures in the group have
any overloading context; and we can't answer that question for HsTypes.
See Note [Partial type signatures and the monomorphism restriction]
in GHC.Tc.Gen.Bind.
This latter is really a pre-existing bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to the fix to #20836 in CorePrep, we now track the set of enclosing
recursive binders in the SimplEnv and SimpleOptEnv.
See Note [Eta reduction in recursive RHSs] for details.
I also updated Note [Arity robustness] with the insights Simon and I had in a
call discussing the issue.
Fixes #21652.
Unfortunately, we get a 5% ghc/alloc regression in T16577. That is due to
additional eta reduction in GHC.Read.choose1 and the resulting ANF-isation
of a large list literal at the top-level that didn't happen before (presumably
because it was too interesting to float to the top-level). There's not much we
can do about that.
Metric Increase:
T16577
|
|
|
|
|
|
|
|
|
|
|
| |
In #20836 we have optimised a terminating program into an endless loop,
because we speculated the self-recursive call of a recursive DFun.
Now we track the set of enclosing recursive binders in CorePrep to prevent
speculation of such self-recursive calls.
See the updates to Note [Speculative evaluation] for details.
Fixes #20836.
|