| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
It isn't used in ghcjs either
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First rebase of the JS-Backend. This rebase includes the JS backend
combined with !7442 (new backend design). Unfortunately we have to short
circuit the new backend design because the JS backend takes over after
STG and not after StgToCmm.
What's working:
- hadrian builds JS backend
- JS backend outputs .js files and "links" them
What still has to be done:
- JS backend is missing core js libraries as we add these we
discover bugs in the linker and js rts.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes #20312
It deprecates "TypeInType" extension
according to the following proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0083-no-type-in-type.rst
It has been already implemented.
The migration strategy:
1. Disable TypeInType
2. Enable both DataKinds and PolyKinds extensions
Metric Decrease:
T16875
|
| |
|
|
|
|
| |
To current `master`.
(cherry picked from commit fbb59c212415188486aafd970eafef170516356a)
|
| |
|
|
|
|
|
|
|
| |
Metric Decrease:
T5631
Metric Increase:
T18223
(cherry picked from commit 55fcee30cb3281a66f792e8673967d64619643af)
|
| |
|
|
| |
Fixes ghc/ghc#21675.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switch to a pure Haskell implementation of base:GHC.Unicode, based on the implementation of the package unicode-data (https://github.com/composewell/unicode-data/).
Approved by CLC as per https://github.com/haskell/core-libraries-committee/issues/59#issuecomment-1132106691.
- Remove current Unicode cbits.
- Add generator for Unicode property files from Unicode Character Database.
- Generate internal modules.
- Update GHC.Unicode.
- Add unicode003 test for general categories and case mappings.
- Add Python scripts to check 'base' Unicode tests outputs and characters properties.
Fixes #21375
-------------------------
Metric Decrease:
T16875
Metric Increase:
T4029
T18304
haddock.base
-------------------------
|
| |
|
|
| |
it is still re-exported from GHC.Exts
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This moves handling of the magic 'withDict' function from the desugarer
to the typechecker. Details in Note [withDict].
I've extracted a part of T16646Fail to a separate file T16646Fail2,
because the new error in 'reify' hides the errors from 'f' and 'g'.
WithDict now works with casts, this fixes #21328.
Part of #19915
|
| |
|
|
|
|
| |
fix #21658
fix #21657
fix #21657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
executablePath support for NetBSD was added in
a172be07e3dce758a2325104a3a37fc8b1d20c9c, but the test was not
updated.
Update the test so that it works for NetBSD. This requires handling
some quirks:
- The result of getExecutablePath could include "./" segments.
Therefore use System.FilePath.equalFilePath to compare paths.
- The sysctl(2) call returns the original executable name even after
it was deleted. Add `canQueryAfterDelete :: [FilePath]` and
adjust expectations for the post-delete query accordingly.
Also add a note to the `executablePath` haddock to advise that
NetBSD behaves differently from other OSes when the file has been
deleted.
Also accept a decrease in memory usage for T16875. On Windows, the
metric is -2.2% of baseline, just outside the allowed ±2%. I don't
see how this commit could have influenced this metric, so I suppose
it's something in the CI environment.
Metric Decrease:
T16875
|
| | |
|
| |
|
|
|
|
| |
These were previously incorrect.
Fixes #21553.
|
| | |
|
| |
|
|
| |
Fixes #21336.
|
| |
|
|
|
| |
This introduces a global hook which is called when an exception is
thrown during finalization.
|
| |
|
|
|
|
| |
This bumps the time submodule to the 1.12.2 release.
Fixes #21571
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This MR fixes a bad bug, where the withDict was inlined too
vigorously, which in turn made the type-class Specialiser generate
a bogus specialisation, because it saw the same overloaded function
applied to two /different/ dictionaries.
Solution: inline `withDict` later. See (WD8) of Note [withDict]
in GHC.HsToCore.Expr
See #21575, which is fixed by this change.
|
| |
|
|
| |
Resolves https://gitlab.haskell.org/ghc/ghc/-/issues/19127
|
| |
|
|
|
|
|
| |
This commit reaffects the new Ix instances of the foreign integral
types from base 4.17 to 4.16.1.0
closes #21529
|
| |
|
|
|
| |
Updates the documentation notes to start tracking changes for
the 9.6.1 release (instead of 9.4).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the new `Note [SubDemand denotes at least one evaluation]`.
A demand `n :* sd` on a let binder `x=e` now means
> "`x` was evaluated `n` times and in any program trace it is evaluated, `e` is
> evaluated deeply in sub-demand `sd`."
The "any time it is evaluated" premise is what this patch adds. As a result,
we get better nested strictness. For example (T21081)
```hs
f :: (Bool, Bool) -> (Bool, Bool)
f pr = (case pr of (a,b) -> a /= b, True)
-- before: <MP(L,L)>
-- after: <MP(SL,SL)>
g :: Int -> (Bool, Bool)
g x = let y = let z = odd x in (z,z) in f y
```
The change in demand signature "before" to "after" allows us to case-bind `z`
here.
Similarly good things happen for the `sd` in call sub-demands `Cn(sd)`, which
allows for more eta-reduction (which is only sound with `-fno-pedantic-bottoms`,
albeit).
We also fix #21085, a surprising inconsistency with `Poly` to `Call` sub-demand
expansion.
In an attempt to fix a regression caused by less inlining due to eta-reduction
in T15426, I eta-expanded the definition of `elemIndex` and `elemIndices`, thus
fixing #21345 on the go.
The main point of this patch is that it fixes #21081 and #21133.
Annoyingly, I discovered that more precise demand signatures for join points can
transform a program into a lazier program if that join point gets floated to the
top-level, see #21392. There is no simple fix at the moment, but !5349 might.
Thus, we accept a ~5% regression in `MultiLayerModulesTH_OneShot`, where #21392
bites us in `addListToUniqDSet`. T21392 reliably reproduces the issue.
Surprisingly, ghc/alloc perf on Windows improves much more than on other jobs, by
0.4% in the geometric mean and by 2% in T16875.
Metric Increase:
MultiLayerModulesTH_OneShot
Metric Decrease:
T16875
|
| |
|
|
|
|
| |
`*Conc*` creation
Fixes https://gitlab.haskell.org/ghc/ghc/-/issues/21420
|
| | |
|
| |
|
|
| |
This makes the Haddocks easier to understand.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In principle, the *visible* instances are
* all instances defined in a prior top-level declaration group
(see docs on `newDeclarationGroup`), or
* all instances defined in any module transitively imported by the
module being compiled
However, actually searching all modules transitively below the one being
compiled is unreasonably expensive, so `reifyInstances` will report only the
instance for modules that GHC has had some cause to visit during this
compilation. This is a shortcoming: `reifyInstances` might fail to report
instances for a type that is otherwise unusued, or instances defined in a
different component. You can work around this shortcoming by explicitly importing the modules
whose instances you want to be visible. GHC issue #20529
has some discussion around this.
Fixes #20529
|
| |
|
|
| |
Update to current `master`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As #21343 showed, we need to be super-certain that the "helper
methods" for Enum instances are actually inlined or specialised.
I also tripped over this when I discovered that numericEnumFromTo
and friends had no pragmas at all, so their performance was very
fragile. If they weren't inlined, all bets were off. So I've added
INLINE pragmas for them too.
See new Note [Inline Enum method helpers] in GHC.Enum.
I also expanded Note [Checking for INLINE loop breakers] in
GHC.Core.Lint to explain why an INLINE function might temporarily
be a loop breaker -- this was the initial bug report in #21343.
Strangely we get a 16% runtime allocation decrease in
perf/should_run/T15185, but only on i386. Since it moves in the right
direction I'm disinclined to investigate, so I'll accept it.
Metric Decrease:
T15185
|
| | |
|
| |
|
|
|
|
|
| |
This module exports unsafe pointer equality operations,
so we accordingly mark it as Unsafe.
Fixes #21433
|
| | |
|
| |
|
|
| |
This should fix #21352
|
| | |
|