| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 4512ad2d6a8e65ea43c86c816411cb13b822f674.
This was never applied to master/9.6 originally.
(cherry picked from commit a44bdc2720015c03d57f470b759ece7fab29a57a)
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes the BFD style import library support in the runtime
linker. This was accidentally broken during the refactoring to clang
and went unnoticed because clang itself is unable to generate the BFD
style import libraries.
With this change we can not link against both GCC or Clang produced
libraries again and intermix code produced by both compilers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #22807 pointed out that the RHS sharing was not compatible with
-fignore-interface-pragmas because the flag would remove unfoldings from
identifiers before the `extra-decls` field was populated.
For the 9.6 timescale the only solution is to disable this sharing,
which will make interface files bigger but this is acceptable for the
first release of `-fwrite-if-simplified-core`.
For 9.8 it would be good to fix this by implementing #20056 due to the
large number of other bugs that would fix.
I also improved the error message in tc_iface_binding to avoid the "no match
in record selector" error but it should never happen now as the entire
sharing logic is disabled.
Also added the currently broken test for #22807 which could be fixed by
!6080
Fixes #22807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR runs the testsuite for the JS backend. Note that this is a
temporary solution until !9515 is merged.
Key point: The CI runs hadrian on the built cross compiler _but not_ on
the bindist.
Other Highlights:
- stm submodule gets a bump to mark tests as broken
- several tests are marked as broken or are fixed by adding more
- conditions to their test runner instance.
List of working commit messages:
CI: test cross target _and_ emulator
CI: JS: Try run testsuite with hadrian
JS.CI: cleanup and simplify hadrian invocation
use single bracket, print info
JS CI: remove call to test_compiler from hadrian
don't build haddock
JS: mark more tests as broken
Tracked in https://gitlab.haskell.org/ghc/ghc/-/issues/22576
JS testsuite: don't skip sum_mod test
Its expected to fail, yet we skipped it which automatically makes it
succeed leading to an unexpected success,
JS testsuite: don't mark T12035j as skip
leads to an unexpected pass
JS testsuite: remove broken on T14075
leads to unexpected pass
JS testsuite: mark more tests as broken
JS testsuite: mark T11760 in base as broken
JS testsuite: mark ManyUnbSums broken
submodules: bump process and hpc for JS tests
Both submodules has needed tests skipped or marked broken for th JS
backend. This commit now adds these changes to GHC.
See:
HPC: https://gitlab.haskell.org/hpc/hpc/-/merge_requests/21
Process: https://github.com/haskell/process/pull/268
remove js_broken on now passing tests
separate wasm and js backend ci
test: T11760: add threaded, non-moving only_ways
test: T10296a add req_c
T13894: skip for JS backend
tests: jspace, T22333: mark as js_broken(22573)
test: T22513i mark as req_th
stm submodule: mark stm055, T16707 broken for JS
tests: js_broken(22374) on unpack_sums_6, T12010
dont run diff on JS CI, cleanup
fixup: More CI cleanup
fix: align text to master
fix: align exceptions submodule to master
CI: Bump DOCKER_REV
Bump to ci-images commit that has a deb11 build with node. Required for
!9552
testsuite: mark T22669 as js_skip
See #22669
This test tests that .o-boot files aren't created when run in using the
interpreter backend. Thus this is not relevant for the JS backend.
testsuite: mark T22671 as broken on JS
See #22835
base.testsuite: mark Chan002 fragile for JS
see #22836
revert: submodule process bump
bump stm submodule
New hash includes skips for the JS backend.
testsuite: mark RnPatternSynonymFail broken on JS
Requires TH:
- see !9779
- and #22261
compiler: GHC.hs ifdef import Utils.Panic.Plain
|
|
|
|
|
|
|
|
| |
This implements proposal 555 and closes ticket #22465.
See the proposal and ticket for motivation.
The core changes of this patch are in the GHC.Core.Rules.match function
and they are explained in the Note [Matching higher order patterns].
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider (#22849)
data T a where
MkT :: forall k (t::k->*) (ix::k). t ix -> T @k a
Then dubiousDataConInstArgTys MkT [Type, Foo] should return
[Foo (ix::Type)]
NOT [Foo (ix::k)]
A bit of an obscure case, but it's an outright bug, and the fix is easy.
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a subtle bug in the typechecking of type
applications in patterns, e.g.
f (MkT @Int @a x y) = ...
See Note [Type applications in patterns] in GHC.Tc.Gen.Pat.
This fixes #19847, #22383, #19577, #21501
|
|
|
|
|
|
|
|
| |
Currently, the wasm NCG has an implicit assumption: all CmmSwitch
scrutinees are 32-bit integers. This is not always true; #22864 is one
counter-example with a 64-bit scrutinee. This patch fixes the logic by
explicitly converting the scrutinee to a word that can be used as a
br_table operand. Fixes #22871. Also includes a regression test.
|
| |
|
|
|
|
| |
Fixes #11270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes #22745 and #15205, which are about GHC's
failure to discard unnecessary superclass selections that
yield coercions. See
GHC.Core.Utils Note [exprOkForSpeculation and type classes]
The main changes are:
* Write new Note [NON-BOTTOM_DICTS invariant] in GHC.Core, and
refer to it
* Define new function isTerminatingType, to identify those
guaranteed-terminating dictionary types.
* exprOkForSpeculation has a new (very simple) case for ClassOpId
* ClassOpId has a new field that says if the return type is
an unlifted type, or a terminating type.
This was surprisingly tricky to get right. In particular note
that unlifted types are not terminating types; you can write an
expression of unlifted type, that diverges. Not so for dictionaries
(or, more precisely, for the dictionaries that GHC constructs).
Metric Decrease:
LargeRecord
|
|
|
|
|
|
| |
gamma is a glibc-only deprecated function, use tgamma instead. It's
required for fixing cg007 when testing the wasm unregisterised
codegen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key change is that in GHC.Core.Opt.Specialise.specLookupRule
we were using realIdUnfolding, which ignores the loop-breaker
flag. When given a loop breaker, rule matching therefore
looped infinitely -- #22802.
In fixing this I refactored a bit.
* Define GHC.Core.InScopeEnv as a data type, and use it.
(Previously it was a pair: hard to grep for.)
* Put several functions returning an IdUnfoldingFun into
GHC.Types.Id, namely
idUnfolding
alwaysActiveUnfoldingFun,
whenActiveUnfoldingFun,
noUnfoldingFun
and use them. (The are all loop-breaker aware.)
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes two issues in the way that `type data` declarations were
reified with Template Haskell:
* `type data` data constructors are now properly reified using `DataConI`.
This is accomplished with a special case in `reifyTyCon`. Fixes #22818.
* `type data` type constructors are now reified in `reifyTyCon` using
`TypeDataD` instead of `DataD`. Fixes #22819.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike most other data constructors, data constructors declared with `type data`
are represented in `TyThing`s as `ATyCon` rather than `ADataCon`. The `ATyCon`
case in `tyThingParent_maybe` previously did not consider the possibility of
the underlying `TyCon` being a promoted data constructor, which led to the
oddities observed in #22817. This patch adds a dedicated special case in
`tyThingParent_maybe`'s `ATyCon` case for `type data` data constructors to fix
these oddities.
Fixes #22817.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use keepCAFsForGHCi.c to force -fkeep-cafs behaviour by using a
__attribute__((constructor)) function.
This broke for static builds where the linker discarded the object file
since it was not reverenced from any exported code. We fix this by
asserting that the flag is enabled using a function in the same module
as the constructor. Which causes the object file to be retained by the
linker, which in turn causes the constructor the be run in static builds.
This changes nothing for dynamic builds using the ghc library. But causes
static to also retain CAFs (as we expect them to).
Fixes #22417.
-------------------------
Metric Decrease:
T21839r
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Incredibly, we previously did not have a single way which would test the
threaded RTS with multiple capabilities and the sanity-checker enabled.
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
See Note [Unwrap newtypes first], which has the details.
Close #22519.
|
|
|
|
|
|
|
|
|
| |
Nothing deep here; I had failed to bring some
floated dictionary binders into scope.
Exposed by -fspecialise-aggressively
Fixes #22715.
|
|
|
|
|
|
| |
This was fixed by b13c6ea5
Closes #22671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to preserve existing behaviour it's important to look within the current component before consideirng a module might come from an external component.
This already happened by accident in `downsweep`, (because roots are used to repopulated the cache) but in the `Finder` the logic was the wrong way around.
Fixes #22680
-------------------------
Metric Decrease:
MultiComponentModules
MultiComponentModulesRecomp
-------------------------p
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple units can refer to the same files without any problem. Just
another assumption which needs to be updated when we may have multiple
home units.
However, there is the invariant that within each unit each file only
maps to one module, so as long as we also key the cache by UnitId then
we are all good.
This led to some confusing behaviour in GHCi when reloading,
multipleHomeUnits_shared distils the essence of what can go wrong.
Fixes #22679
|
|
|
|
|
|
|
|
|
|
| |
Currently the driver diagnostics don't give any indication about which unit they correspond to.
For example `-Wmissing-home-modules` can fire multiple times for each different home unit and gives no indication about which unit it's actually reporting about.
Perhaps a longer term fix is to generalise the providence information away from a SrcSpan so that these kind of whole project errors can be reported with an accurate provenance. For now we can just include the `UnitId` in the error message.
Fixes #22678
|
|
|
|
|
|
|
|
| |
We should not be producing object files when in interactive mode but we
still produced the dummy o-boot files. These never made it into a
`Linkable` but then confused the recompilation checker.
Fixes #22669
|
|
|
|
|
|
|
|
|
|
|
|
| |
satisfies target
This fixes a spurious warning in -Wmissing-home-modules.
This is a simple oversight where when looking for the target in the
first place we augment the search by the -working-directory flag but
then fail to do so when checking this warning.
Fixes #22676
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key part of this change is to store a UnitId in the
`UsageHomeModule` and `UsageHomeModuleInterface`.
* Fine-grained dependency tracking is used if the dependency comes from
any home unit.
* We actually look up the right module when checking whether we need to
recompile in the `UsageHomeModuleInterface` case.
These scenarios are both checked by the new tests (
multipleHomeUnits_recomp and multipleHomeUnits_recomp_th )
Fixes #22675
|
|
|
|
|
|
|
|
|
| |
...the testsuite doesn't handle this properly since it
also collects run-time metrics. Compile-time metrics
for this test are already tracked via T21839c.
Metric Decrease:
T21839r
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtimeRepLevity_maybe was panicing unnecessarily; and
the error printing code made use of the case when it should
return Nothing rather than panicing.
For some bizarre reason perf/compiler/T21839r shows a 10% bump in runtime
peak-megagbytes-used, on a single architecture (alpine). See !9753 for
commentary, but I'm going to accept it.
Metric Increase:
T21839r
|
|
|
|
|
|
| |
Updates `text` and `exceptions` submodules for bounds bumps.
Addresses #22767.
|
|
|
|
|
|
| |
To be able to capture string literals with possible escape codes as labels.
Close #22771
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: In 2463df2f, the Solo data constructor was renamed to MkSolo,
and Solo was turned into a pattern synonym for backwards compatibility.
Since pattern synonyms can not be promoted, the old code that pretty-printed
promoted single-element tuples started producing ill-typed code:
t :: Proxy ('Solo Int)
This fails with "Pattern synonym ‘Solo’ used as a type"
The solution is to track the distinction between type constructors and data
constructors more carefully when printing single-element tuples.
|
|
|
|
|
|
|
|
|
| |
Issue #22151 was coincidentally fixed in commit
aed1974e92366ab8e117734f308505684f70cddf (`Refactor the treatment of loopy
superclass dicts`). This adds a regression test to ensure that the issue
remains fixed.
Fixes #22151.
|
|
|
|
|
|
|
|
| |
This adds `-Werror=<group>` and `-fwarn-<group>` flags for warning
groups as well as individual warnings. Previously these were defined
on an ad hoc basis so for example we had `-Werror=compat` but not
`-Werror=unused-binds`, whereas we had `-fwarn-unused-binds` but not
`-fwarn-compat`. Fixes #22182.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for calling Cmm code from bytecode using the native
calling convention, allowing modules that use `foreign import prim`
to be loaded and debugged in GHCi.
This patch introduces a new `PRIMCALL` bytecode instruction and
a helper stack frame `stg_primcall`. The code is based on the
existing functionality for dealing with unboxed tuples in bytecode,
which has been generalised to handle arbitrary calls.
Fixes #22051
|
|
|
|
|
| |
Corrects a typo in !9647. Otherwise T18623 will still fail on darwin
and stall other people's work.
|
|
|
|
|
|
|
|
| |
We need to ensure that the output of `cvtSigTypeKind` is parenthesized (at
precedence `sigPrec`) so that any type signatures with an outermost, explicit
kind signature can parse correctly.
Fixes #22784.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following the plan in GHC Proposal #143 "Remove the * kind syntax",
which states:
In the next release (or 3 years in), enable -fwarn-star-is-type by default.
The "next release" happens to be 9.6.1
I also moved the T21583 test case from should_fail to should_compile,
because the only reason it was failing was -Werror=compat in our test
suite configuration.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See #22630 and !9552
This commit:
- splits req_smp into req_target_smp and req_ghc_smp
- changes the testsuite driver to calculate req_ghc_smp
- changes a handful of tests to use req_target_smp instead of req_smp
- changes a handful of tests to use req_host_smp when needed
The problem:
- the problem this solves is the ambiguity surrounding req_smp
- on master req_smp was used to express the constraint that the program
being compiled supports smp _and_ that the host RTS (i.e., the RTS used
to compile the program) supported smp. Normally that is fine, but in
cross compilation this is not always the case as was discovered in #22630.
The solution:
- Differentiate the two constraints:
- use req_target_smp to say the RTS the compiled program is linked
with (and the platform) supports smp
- use req_host_smp to say the RTS the host is linked with supports smp
WIP: fix req_smp (target vs ghc)
add flag to separate bootstrapper
split req_smp -> req_target_smp and req_ghc_smp
update tests smp flags
cleanup and add some docstrings
only set ghc_with_smp to bootstrapper on S1 or CC
Only set ghc_with_smp to bootstrapperWithSMP of when testing stage 1
and cross compiling
test the RTS in config/ghc not hadrian
re-add ghc_with_smp
fix and align req names
fix T11760 to use req_host_smp
test the rts directly, avoid python 3.5 limitation
test the compiler in a try block
align out of tree and in tree withSMP flags
mark failing tests as host req smp
testsuite: req_host_smp --> req_ghc_smp
Fix ghc vs host, fix ghc_with_smp leftover
|
|
|
|
| |
This MR is in response to the discussion on #22719
|
|
|
|
| |
Closes #22765
|