| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
[skip ci]
|
| |
|
|
| |
Issue #12770
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GHCi debugger has never been that robust in the face of
higher-rank types, or even types that are _interally_ higher-rank,
such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
however, things became even worse, as the debugger would start to
_panic_ when a user tries passing the name of a higher-rank thing
to `:print`. This all ties back to a strange `isUnliftedType` check
in `Debugger` that was mysteriously added 11 years ago
(in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no
explanation whatsoever.
After some experimentation, no one is quite sure what this
`isUnliftedType` check is actually accomplishing. The test suite
still passes if it's removed, and I am unable to observe any
differences in debugger before even with data types that _do_ have
fields of unlifted types (e.g., `data T = MkT Int#`). Given that
this is actively causing problems (see #14828), the prudent thing
to do seems to be just removing this `isUnliftedType` check, and
waiting to see if anyone shouts about it. This patch accomplishes
just that.
Note that this patch fix the underlying issues behind #14828, as the
debugger will still print unhelpful info if you try this:
```
λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
λ> :print f
f = (_t1::t1)
```
But fixing this will require much more work, so let's start with the
simple stuff for now.
|
| | |
|
| |
|
|
|
|
|
|
| |
The `dataConCannotMatch` function (which powers the
`-Wpartial-fields` warning, among other things) had special reasoning
for explicit equality constraints of the form `a ~ b`, but it did
not extend that reasoning to `a ~~ b` constraints, leading to #16411.
Easily fixed.
|
| |
|
|
|
|
|
|
|
| |
With all the recent fixes to the binary-dist rule in Hadrian, we can now run
that rule in CI and keep the bindists around in gitlab as artifacts, just like
we do for the make CI jobs.
To get 'autoreconf' to work in the Windows CI, we have to run it through the
shell interpreter, so this commit does that along the way.
|
| |
|
|
| |
See #15382.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Commit 1f5cc9dc8aeeafa439d6d12c3c4565ada524b926 ended up
fixing #16347. Let's add a regression test to ensure that it stays
fixed.
|
| |
|
|
| |
Also remove unused arg from get_Regtable_addr_from_offset
|
| |
|
|
|
|
|
|
|
|
| |
Code in TcErrors was recursively using immSuperClasses,
which loops in the presence of UndecidableSuperClasses.
Better to use transSuperClasses instead, which has a loop-breaker
mechanism built in.
Fixes issue #16414.
|
| | |
|
| |
|
|
|
|
| |
This is a separate build job to the other hadrian jobs as it only takes
about 2-3 minutes to run from cold. The CI tests that the
`./hadrian/ghci` script loads `ghc/Main.hs` successfully.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running the `./hadrian/ghci` target will load the main compiler into
a ghci session. This is intended for fast development feedback, modules are only
typechecked so it isn't possible to run any functions in the repl.
You can also use this target with `ghcid`.
The first time this command is run hadrian will need to compile a few dependencies
which will take 1-2 minutes. Loading GHC into GHCi itself takes about 30 seconds.
Internally this works by calling a new hadrian target called `tool-args`.
This target prints out the package and include flags which are necessary
to load files into ghci. The same target is intended to be used by other
tooling which uses the GHC API in order to set up the correct GHC API
session. For example, using this target it is also possible to use HIE
when developing on GHC.
|
| |
|
|
|
|
| |
After being copied all the shared objects end up in the same directory.
Therefore the correct rpath is `$ORIGIN` rather than the computed
path which is relative to the directory where it is built.
|
| |
|
|
|
|
| |
makeRelativeNoSysLink would previously crash for no reason if the first
argument as `./` due to the call to `head`. This refactoring keeps the
behaviour the same but doesn't crash in this corner case.
|
| |
|
|
|
| |
The version suffix needs to be the version of the stage 0 compiler
when building shared libraries with the stage 0 compiler.
|
| |
|
|
|
| |
Setting `CABFLAGS=args` will pass the additional arguments to cabal
when it is invoked.
|
| |
|
|
| |
It no longer gives a warning.
|
| |
|
|
|
|
|
| |
We'd like to enforce the substitution invariant (Trac #11371).
In a492af06d326453 the assertion was downgraded to a warning;
I'm restoring the assertion and making the calls that
don't maintain the invariant as unchecked.
|
| |
|
|
|
|
|
|
|
| |
Prevents some tests from failing just due to mismatched version numbers.
These version numbers shouldn't cause tests to fail, especially since
we *expect* them to be regularly incremented. The motivation for this
particular set of changes came from the changes that came along with
the `base` version bump in 8f19ecc95fbaf2cc977531d721085d8441dc09b7.
|
| |
|
|
|
| |
This doesn't appear to be used anywhere in the build system and it
relies on perl. Drop it.
|
| |
|
|
|
|
| |
The object splitter was the last major user of perl. There remain a few
uses in nofib but we can just rely on the system's perl for this since
it's not critical to the build.
|
| |
|
|
|
| |
GHC native code generator generates .incbin and .file directives. We
need to escape those strings correctly on Windows (see #16389).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, our test did something like this:
1. Typecheck p
2. Typecheck q (which made use of an instantiated p)
3. Build instantiated p
4. Build instantiated q
Cabal previously permitted this, under the reasoning that during
typechecking there's no harm in using the instantiated p even if we
haven't build it yet; we'll just instantiate it on the fly with p.
However, this is not true! If q makes use of a Template Haskell
splice from p, we absolutely must have built the instantiated p
before we typecheck q, since this typechecking will need to
run some splices. Cabal now complains that you haven't done
it correctly, which we indeed have not!
Reordering so that we do this:
1. Typecheck p
3. Build instantiated p
2. Typecheck q (which made use of an instantiated p)
4. Build instantiated q
Fixes the problem. If Cabal had managed the ordering itself, it would
have gotten it right.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
|
| |
|
|
|
| |
This will be needed by the mark phase of the non-moving collector
so let's factor it out.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue was reproduced with, and the fix confirmed with,
the `hatrace` tool for syscall-based fault injection:
https://github.com/nh2/hatrace
The concrete test case for GHC is at
https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185
A previous, nondeterministic reproducer for the issue was provided by
Alexey Kuleshevich in
https://github.com/lehins/exec-kill-loop
Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com>
Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch GHC was trying to be too clever
(Trac #16344); it succeeded in kind-checking this
polymorphic-recursive declaration
data T ka (a::ka) b
= MkT (T Type Int Bool)
(T (Type -> Type) Maybe Bool)
As Note [No polymorphic recursion] discusses, the "solution" was
horribly fragile. So this patch deletes the key lines in
TcHsType, and a wodge of supporting stuff in the renamer.
There were two regressions, both the same: a closed type family
decl like this (T12785b) does not have a CUSK:
type family Payload (n :: Peano) (s :: HTree n x) where
Payload Z (Point a) = a
Payload (S n) (a `Branch` stru) = a
To kind-check the equations we need a dependent kind for
Payload, and we don't get that any more. Solution: make it
a CUSK by giving the result kind -- probably a good thing anyway.
The other case (T12442) was very similar: a close type family
declaration without a CUSK.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC represents String literals as ByteString internally for efficiency
reasons. However, until now it wasn't possible to efficiently create
large string literals with TH (e.g. to embed a file in a binary, cf #14741):
TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
into a ByteString.
This patch adds the possibility to efficiently create a "string" literal
from raw bytes. We get the following compile times for different sizes
of TH created literals:
|| Size || Before || After || Gain ||
|| 30K || 2.307s || 2.299 || 0% ||
|| 3M || 3.073s || 2.400s || 21% ||
|| 30M || 8.517s || 3.390s || 60% ||
Ticket #14741 can be fixed if the original code uses this new TH feature.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #16376 showed the danger of failing to report an error
that exists only in the unsolved constraints, if an exception
is raised (via failM).
Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
did just that -- i.e. it found errors in the constraints, and
called failM to avoid a misleading cascade.
So we need to be sure to call captureTopConstraints to report
those insolubles. This was wrong in TcRnDriver.tcRnExpr and
in TcRnDriver.tcRnType.
As a result the error messages from test T13466 improved slightly,
a happy outcome.
|
| |
|
|
|
| |
Also, replace some tabs with spaces to avoid a "mixed indent" warning that vim
gives me.
|
| |
|
|
|
|
|
|
|
|
| |
This partly resolves #16325 (https://ghc.haskell.org/trac/ghc/ticket/16325).
As previously discussed in https://github.com/snowleopard/hadrian/issues/667,
we do not need the symlink traversal code in build scripts. However, it
appears we forgot to delete this code from our Stack-based build scripts,
which led to placing all build artefacts in an unexpected location when
using Hadrian in combination with symlink trees. This commit fixes this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- introduce a -k/--keep-test-files flag to prevent cleanup
- add -dstg-lint to the options that are always passed to tests
- infer library ways from the compiler to be tested instead of getting them
from the flavour (like make)
- likewise for figuring out whether the compiler to be tested is "debugged"
- specify config.exeext
- correctly specify config.in_tree_compiler, instead of always passing True
- fix formatting of how we pass a few test options
- add (potential) extensions to check-* program names
- build check-* programs with the compiler to be tested
- set TEST_HC_OPTS_INTERACTIVE and PYTHON env vars when running tests
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10069 revealed that small NOINLINE functions didn't get split
into worker and wrapper. This was due to `certainlyWillInline`
saying that any unfoldings with a guidance of `UnfWhen` inline
unconditionally. That isn't the case for NOINLINE functions, so we
catch this case earlier now.
Nofib results:
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
fannkuch-redux -0.3% 0.0%
gg +0.0% +0.1%
maillist -0.2% -0.2%
minimax 0.0% -0.8%
--------------------------------------------------------------------------------
Min -0.3% -0.8%
Max +0.0% +0.1%
Geometric Mean -0.0% -0.0%
Fixes #10069.
-------------------------
Metric Increase:
T9233
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The type-variables-escaping-their-scope-via-kinds check in
`TcValidity` was failing to properly expand type synonyms, which led
to #16391. This is easily fixed by using `occCheckExpand` before
performing the validity check.
Along the way, I refactored this check out into its own function,
and sprinkled references to Notes to better explain all of the moving
parts. Many thanks to @simonpj for the suggestions.
Bumps the haddock submodule.
|
| |
|
|
|
|
|
|
|
| |
We revert CAFs when loading/adding modules in ghci (presumably to refresh
execution states and to allow for object code to be unloaded from the runtime).
However, with `-fexternal-interpreter` enabled, we are only doing it in the
ghci process instead of the external interpreter process where the cafs are
allocated and computed. This makes sure that revertCAFs is done in the
appropriate process no matter if that flag is present or not.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Also account for testsuite metric drift.
Metric Increase:
haddock.Cabal
haddock.base
T14683
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Now since we have been a bit more stringent in testsuite cleanliness we
have been marking a lot of tests as fragile using the `skip` modifier.
However, this unfortunately means that we lose the association with the
ticket number documenting the fragility.
Here we introduce `fragile` and `fragile_for` to retain this
information.
|
| |
|
|
| |
This was the suggested change in !176 but missed the batch merge (!263).
|
| |
|
|
|
|
|
|
|
| |
`instance forall c. c` claimed that `c` was out of scope because the
renamer was invoking `lookupGlobalOcc` on `c` (in
`RnNames.getLocalNonValBinders`) without binding `c` first. To avoid
this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c`
instead, and if that returns `Nothing`, then bail out, resulting
in a better error message.
|
| | |
|
