| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
In particular we do not have a release job for FreeBSD so the generation
of the platform mapping was failing.
|
|
|
|
|
|
| |
These were not uploaded for alpha1
Fixes #22844
|
|
|
|
|
|
| |
This check makes sure that if a job is a prefixed by "release-" then the
script downloads it and understands how to map the job name to the
platform.
|
|
|
|
| |
We no longer attempt to build or distribute this release
|
|
|
|
|
|
|
| |
The CmmBlock datacon was not handled in lower_CmmLit, since I thought
it would have been eliminated after proc-point splitting. Turns out it
still occurs in very rare occasions, and this patch is needed to fix
T9329 for wasm.
|
|
|
|
|
|
| |
This patch fixes the W8/W16 literal narrowing logic in the wasm NCG,
which used to lower it to something like i32.const -1, without
properly zeroing-out the unused higher bits. Fixes #22608.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inplace .conf files
Previously we were just throwing away the contents of the library-dirs
fields but really we have to do the same thing as for include-dirs,
relativise the paths into the current working directory and maintain any
extra libraries the user has specified.
Now the relevant section of the rts.conf file looks like:
```
library-dirs:
${pkgroot}/../rts/build
${pkgroot}/../../..//_build/stage1/rts/build
/nix/store/av4c0fib4rkmb6sa1074z0rb1ciria5b-gperftools-2.10/lib
/nix/store/2infxahfp9lj084xn3q9ib5ajks8447i-libffi-3.4.4/lib
library-dirs-static:
${pkgroot}/../rts/build
${pkgroot}/../../..//_build/stage1/rts/build
/nix/store/av4c0fib4rkmb6sa1074z0rb1ciria5b-gperftools-2.10/lib
/nix/store/2infxahfp9lj084xn3q9ib5ajks8447i-libffi-3.4.4/lib
dynamic-library-dirs:
${pkgroot}/../rts/build
${pkgroot}/../../..//_build/stage1/rts/build
/nix/store/av4c0fib4rkmb6sa1074z0rb1ciria5b-gperftools-2.10/lib
/nix/store/2infxahfp9lj084xn3q9ib5ajks8447i-libffi-3.4.4/lib
```
Fixes #22209
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I removed all occurrences of TcRnUnknownMessage in GHC.Rename.Bind
module. Instead, these TcRnMessage messages were introduced:
TcRnMultipleFixityDecls
TcRnIllegalPatternSynonymDecl
TcRnIllegalClassBiding
TcRnOrphanCompletePragma
TcRnEmptyCase
TcRnNonStdGuards
TcRnDuplicateSigDecl
TcRnMisplacedSigDecl
TcRnUnexpectedDefaultSig
TcRnBindInBootFile
TcRnDuplicateMinimalSig
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when using `capi` calling convention in foreign declarations,
code generator failed to handle const-cualified pointer return types.
This resulted in CC toolchain throwing `-Wincompatible-pointer-types-discards-qualifiers`
warning.
`Foreign.C.Types.ConstPtr` newtype was introduced to handle these cases -
special treatment was put in place to generate appropritetly qualified C
wrapper that no longer triggers the above mentioned warning.
Fixes #22043.
|
|
|
|
|
|
| |
types (#22043)"
This reverts commit 99aca26b652603bc62953157a48e419f737d352d.
|
|
|
|
| |
These are no longer necessary since we now compile as C99.
|
|
|
|
| |
"tracingAddCapabilities" was mis-named
|
|
|
|
|
| |
Make the RTS compilable with a C++ compiler by inserting necessary
casts.
|
| |
|
|
|
|
|
| |
Previously it was sensitive to the labels of threads which it did not
create (e.g. the IO manager event loop threads). Fix this.
|
|
|
|
|
|
|
|
|
| |
Previously UnliftedTVar2 would fail when run with multiple capabilities
(and possibly even with one capability) as it would assume that
`killThread#` would immediately kill the "increment" thread.
Also, refactor the the executable to now succeed with no output and
fails with an exit code.
|
|
|
|
|
|
|
| |
`doneWithMsgThrowTo` was previously too strict in asserting that the
`Message` is locked. Specifically, it failed to consider that the
`Message` may not be locked if we are deleting all threads during RTS
shutdown.
|
|
|
|
|
| |
Incredibly, we previously did not have a single way which would test the
threaded RTS with multiple capabilities and the sanity-checker enabled.
|
|
|
|
|
| |
This makes it possible to review changes with conventional diffing
tools.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This accepts the orphan type family instance
type instance DsForeignHook = ...
in GHC.HsToCore.Types.
See Note [The Decoupling Abstract Data Hack] in GHC.Driver.Hooks
|
|
|
|
|
| |
This moves Anno instances for PatBuilder from GHC.Parser.PostProcess
to GHC.Parser.Types to avoid orphans.
|
|
|
|
|
|
|
| |
This patch removes some orphan instances in the STG namespace
by introducing the GHC.Stg.Lift.Types module, which allows various
type family instances to be moved to GHC.Stg.Syntax, avoiding orphan
instances.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the fact that we were not reporting orphan family instances
at all. The fix here is easy, but touches a bit of code. I refactored
the code to be much more similar to the way that class instances are done:
- Add a fi_orphan field to FamInst, like the is_orphan field in ClsInst
- Make newFamInst initialise this field, just like newClsInst
- And make newFamInst report a warning for an orphan, just like newClsInst
- I moved newFamInst from GHC.Tc.Instance.Family to GHC.Tc.Utils.Instantiate,
just like newClsInst.
- I added mkLocalFamInst to FamInstEnv, just like mkLocalClsInst in InstEnv
- TcRnOrphanInstance and SuggestFixOrphanInstance are now parametrised
over class instances vs type/data family instances.
Fixes #19773
|
|
|
|
|
|
|
|
|
| |
We were treating a type-family instance as a non-orphan if there
was a type constructor on its /right-hand side/ that was local. Boo!
Utterly wrong. With this patch, we correctly check the /left-hand side/
instead!
Fixes #22717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes CI errors of the form.
```
===> Command failed with error code: 1
ghc: panic! (the 'impossible' happened)
GHC version 9.7.20230127:
lookupGlobal
Failed to load interface for ‘GHC.Num.BigNat’
There are files missing in the ‘ghc-bignum’ package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Tc/Utils/Env.hs:154:32 in ghc:GHC.Tc.Utils.Env
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
This reverts commit d0d7ba0fb053ebe7f919a5932066fbc776301ccd.
The module now lacks a dependency on GHC.Num.BigNat which it implicitly
depends on. It is causing all CI jobs to fail so we revert without haste
whilst the patch can be fixed.
Fixes #22848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: in 02279a9c the type-level [] syntax was changed from a built-in name
to an alias for the GHC.Types.List constructor. badOrigBinding assumes that if
a name is not built-in then it must have come from TH quotation, but this is
not necessarily the case with [].
The outdated assumption in badOrigBinding leads to incorrect error messages.
This code:
data []
Fails with "Cannot redefine a Name retrieved by a Template Haskell quote: []"
Unfortunately, there is not enough information in RdrName to directly determine
if the name was constructed via TH or by the parser, so this patch changes the
error message instead.
It unifies TcRnIllegalBindingOfBuiltIn and TcRnNameByTemplateHaskellQuote
into a new error TcRnBindingOfExistingName and changes its wording to avoid
guessing the origin of the name.
|
|
|
|
|
|
|
| |
Previously we used `static_assert` which is only available in C23. By
contrast, C11 only provides `_Static_assert`.
Fixes #22777
|
| |
|
|
|
|
| |
Addresses #22773.
|
|
|
|
|
| |
We intend to release rocky8 bindist so the fetching script needs to know
about them.
|
|
|
|
|
|
|
| |
This adds release jobs for ubuntu18_04 which uses glibc 2.27 which is
older than the 2.28 which is used by Rocky8 bindists.
Ticket #22268
|
|
|
|
|
| |
This change removes an unnecessary dependency on Prelude
from two modules in the base package.
|
|
|
|
| |
more speculative bangs
|
|
|
|
|
|
| |
See Note [Unwrap newtypes first], which has the details.
Close #22519.
|
|
|
|
|
| |
Was missing dependencies on files generated by templates (e.g.
ghc.cabal)
|
|
|
|
| |
Towards #22530
|
|
|
|
|
|
|
| |
This occname has just been derived from an `Id`, so need to force it
promptly so we can release the Id back to the world.
Another symptom of the bug caused by #19619
|
|
|
|
|
|
|
|
|
|
|
| |
Doesn't force the lazy `OccName` field (#19619) which is already known
as a really bad source of leaks.
When we slam the hammer storing Names on disk (in interface files or the
like), all this should be forced as otherwise a `Name` can easily retain
an `Id` and hence the entire world.
Fixes #22833
|
|
|
|
|
|
|
|
|
| |
This fixes a tricky leak in GHCi where we were retaining old copies of
HscEnvs when reloading. If not all modules were recompiled then these
hydrated fields in break points would retain a reference to the old
HscEnv which could double memory usage.
Fixes #22530
|
|
|
|
|
| |
Create and use moduleGraphModulesBelow in GHC.Unit.Module.Graph that
doesn't need anything from the driver to be used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HLint jobs takes much longer to run (20 minutes) after "Give the RTS it's own configure script" eb5a6b91
Now the CI job will build the stage0 compiler before it generates the necessary RTS headers.
We either need to:
* Fix the linting rules so they take much less time
* Revert the commit
* Remove the linting of base from the hlint job
* Remove the hlint job
This is highest priority as it is affecting all CI pipelines.
For now I am just disabling the job because there are many more pressing
matters at hand.
Ticket #22830
|
|
|
|
|
|
|
|
|
| |
Nothing deep here; I had failed to bring some
floated dictionary binders into scope.
Exposed by -fspecialise-aggressively
Fixes #22715.
|
| |
|
|
|
|
|
| |
This change fixes a cross-compilation issue from ArchLinux to Windows
because these symbols weren't found.
|
|
|
|
|
| |
Decision to build either unix or Win32 package must be stage specific
for cross-compilation to be supported.
|
|
|
|
|
|
| |
Stage0's ar may not support at-files. Take it into account.
Found while cross-compiling from Darwin to Windows.
|
|
|
|
|
|
|
|
| |
In the wasm NCG, we used to compile MO_F_Neg to 0.0-x. It was an
oversight, there actually exists f32.neg/f64.neg opcodes in the wasm
spec and those should be used instead! The old behavior almost works,
expect when GHC compiles the -0.0 literal, which will incorrectly
become 0.0.
|