| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #14037.
Metric Decrease:
T9872b
T9872d
Reviewers: bgamari, simonpj, hvr
Reviewed By: simonpj
Subscribers: AndreasK, simonpj, osa1, dfeuer, rwbarton, carter
GHC Trac Issues: #14037
Differential Revision: https://phabricator.haskell.org/D5249
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We no longer put class variables in front,
see "Taming the Kind Inference Monster"
(also fix some markup issues)
|
| |
|
|
|
|
|
|
|
|
|
| |
While playing around with late lambda lifting, I realised that
StgLamLift.Analysis doesn't consider the removed closure header in its
allocation estimations.
That's because contrary to what I thought, the total word count returned
by `mkVirtHeapOffsets` doesn't include the size of the closure header.
We just add the header size manually now.
|
| |
|
|
| |
These are largely redundant as they are covered by x86_64-deb9.
|
| |
|
|
|
|
| |
This was causing gitlab to not report from builds as failing. It also
highlighted a problem with the LLVM tests where some of the external
interpreter tests are failing.
|
| |
|
|
|
|
|
|
| |
`--supported-languages` must only advertise language extensions
which are supported by the compiler in order for tooling such
as Cabal relying on this signalling not to behave incorrectly.
Fixes #16331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
introducing a new ambiguity resolution system in the parser.
Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a command:
proc x -> do { (stuff) -< x } -- 'stuff' is an expression
proc x -> do { (stuff) } -- 'stuff' is a command
Until we encounter arrow syntax (-<) we don't know whether to parse
'stuff' as an expression or a command.
The old solution was to parse as HsExpr always, and rejig later:
checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
This meant polluting 'HsExpr' with command-related constructors. In
other words, limitations of the parser were affecting the AST, and
all other code (the renamer, the typechecker) had to deal with these
extra constructors by panicking.
We fix this abstraction leak by parsing into an intermediate
representation, 'ExpCmd':
data ExpCmdG b where
ExpG :: ExpCmdG HsExpr
CmdG :: ExpCmdG HsCmd
type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
checkExp f = f ExpG -- interpret as an expression
checkCmd f = f CmdG -- interpret as a command
See Note [Ambiguous syntactic categories] for details.
Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/command ambiguity.
Future work: apply the same principles to the expression/pattern
ambiguity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The big payload of this patch is:
Add an AnonArgFlag to the FunTy constructor
of Type, so that
(FunTy VisArg t1 t2) means (t1 -> t2)
(FunTy InvisArg t1 t2) means (t1 => t2)
The big payoff is that we have a simple, local test to make
when decomposing a type, leading to many fewer calls to
isPredTy. To me the code seems a lot tidier, and probably
more efficient (isPredTy has to take the kind of the type).
See Note [Function types] in TyCoRep.
There are lots of consequences
* I made FunTy into a record, so that it'll be easier
when we add a linearity field, something that is coming
down the road.
* Lots of code gets touched in a routine way, simply because it
pattern matches on FunTy.
* I wanted to make a pattern synonym for (FunTy2 arg res), which
picks out just the argument and result type from the record. But
alas the pattern-match overlap checker has a heart attack, and
either reports false positives, or takes too long. In the end
I gave up on pattern synonyms.
There's some commented-out code in TyCoRep that shows what I
wanted to do.
* Much more clarity about predicate types, constraint types
and (in particular) equality constraints in kinds. See TyCoRep
Note [Types for coercions, predicates, and evidence]
and Note [Constraints in kinds].
This made me realise that we need an AnonArgFlag on
AnonTCB in a TyConBinder, something that was really plain
wrong before. See TyCon Note [AnonTCB InivsArg]
* When building function types we must know whether we
need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
This turned out to be pretty easy in practice.
* Pretty-printing of types, esp in IfaceType, gets
tidier, because we were already recording the (->)
vs (=>) distinction in an ad-hoc way. Death to
IfaceFunTy.
* mkLamType needs to keep track of whether it is building
(t1 -> t2) or (t1 => t2). See Type
Note [mkLamType: dictionary arguments]
Other minor stuff
* Some tidy-up in validity checking involving constraints;
Trac #16263
|
| |
|
|
|
|
|
| |
Remove a bogus assertion in FamInst.newFamInst
(There is a comment to explain.)
This fixes Trac #16112.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Some code is broken, there are no CI targets (so not obvious how to
test), and no one seems to have built GHC for any of the above
platforms in years.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use official bindists, except for Debian 9/Stretch
http://downloads.haskell.org/debian/ is used. (There are no recent
GHC/cabal-install for Debian 8/Jessie there)
Use v2-update/v2-install to install Haskell tools.
Try to unify structure of the different Dockerfiles, incl installing GHC
in one step (this will prevent sublayers from existing, making final
image slightly smaller)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
linking ghc.
Test Plan:
Ensure build environment does NOT have a system libffi installed (you may want to use a nix environment).
Then `hadrian/build.sh -c --flavour=default`
Reviewers: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15837
|
| |
|
|
| |
This also builds stage2 with optimisations and -dcore-lint
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit
commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6
Date: Thu Jan 24 17:58:50 2019 +0100
Look through newtype wrappers (Trac #16254)
we made exprIsConApp_maybe quite a bit cleverer. But I had not paid
enough attention to keeping exactly the correct substitution and
in-scope set, which led to Trac #16348.
There were several buglets (like applying the substitution twice in
exprIsConApp_maybe, but the proximate source of the bug was that we were
calling addNewInScopeIds, which deleted things from the substitution as
well as adding them to the in-scope set. That's usually right, but not
here!
This was quite tricky to track down. But it is nicer now.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch disables the binder-swap transformation in the
(relatively rare) case when the scrutinee is a GlobalId.
Reason: we are getting Lint errors so that GHC doesn't
even validate. Trac #16346.
This is NOT the final solution -- it's just a stop-gap
to get us running again.
The final solution is in Trac #16296
|
| |
|
|
|
|
| |
The tcTyConUserTyVars field of TcTyCon was entirely unused.
This patch kills it off entirely.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| | |
|
| |
|
|
|
| |
By parsing '~' in 'tyconsym' instead of 'oqtycon', we
get one less shift/reduce conflict.
|
| |
|
|
|
|
|
|
| |
The dot type operator was handled in the 'tyvarop' parser production, and the
bang type operator in 'tyapp'. However, export lists and role annotations use
'oqtycon', so these type operators could not be exported or assigned roles.
The fix is to handle them in a lower level production, 'tyconsym'.
|
| |
|
|
| |
Respect `inside_git_repo()` when checking performance stats.
|
| |
|
|
|
|
| |
The `Final` constructor needed to maintain the invariant that the list
it is provided is always non-empty. Since NonEmpty is in `base` now, I
think it would be better to use it for this purpose.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There was a missing case in the very simple optimiser,
CoreOpt.simpleOptExpr, which led to Trac #13208 comment:2.
In particular, in simple_app, if we find a Let, we should
just float it outwards. Otherwise we leave behind some
easy-to-reduce beta-redexes.
|
| |
|
|
| |
No change in behaviour, slightly more efficient
|
| |
|
|
|
|
| |
Alexandre Balde (rockbmb) points out that the fusion technology
for foldr2, zip, zipWith, etc is undocumented. This patch adds
comments to explain.
|
| | |
|
| |
|
|
|
|
|
| |
Along the way, I discovered that `template-haskell.cabal` was
hard-coding the GHC version (in the form of its `ghc-boot-th` version
bounds), so I decided to make life a little simpler in the future by
generating `template-haskell.cabal` with autoconf.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a preparation for #16295: https://ghc.haskell.org/trac/ghc/ticket/16295
This commit mostly focuses on getting rid of untracked dependencies,
which prevent Shake's new `--shared` feature from appropriately caching
build rules.
There are three different solutions to untracked dependencies:
* Track them! This is the obvious and the best approach, but in some
situations we cannot use it, for example, because a build rule creates
files whose names are not known statically and hence cannot be
specified as the rule's outputs.
* Use Shake's `produces` to record outputs dynamically, within the rule.
* Use Shake's `historyDisable` to disable caching for a particular build
rule. We currently use this approach only for `ghc-pkg` which mutates
the package database and the file `package.cache`.
These two tickets are fixed as the result:
Ticket #16271: https://ghc.haskell.org/trac/ghc/ticket/16271
Ticket #16272: https://ghc.haskell.org/trac/ghc/ticket/16272 (this one
is fixed only partially: we correctly record the dependency, but we
still copy files into the RTS build tree).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes two bug fixes in profiling version of stg_ap_0_fast:
- PAPs allocated by stg_ap_0_fast are now correctly tagged. This
invariant is checked in Sanity.c:checkPAP.
(This was originally implemented in 2693eb11f5, later reverted with
ab55b4ddb7 because it revealed the bug below, but it wasn't clear at
the time whether the bug was the one below or something in the commit)
- The local variable `untaggedfun` is now marked as a pointer so it
survives GC.
With this we finally fix all known bugs caught in #15508. `concprog001`
now works reliably with prof+threaded and prof runtimes (with and
without -debug).
|
| | |
|
| |
|
| |
Also add an implementation comment for details.
|
| |
|
|
|
|
| |
exprIsConApp_maybe could detect that I# 10 is a constructor application,
but not that Size (I# 10) is, because it was an application with a
nontrivial argument.
|
| |
|
|
|
|
|
| |
For case-of-known constructor to continue triggering early,
exprIsConApp_maybe is now capable of looking through lets and cases.
See #15840
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move implementation notes for Integer to Haddock named section
Revert documentation named chunk change [skip ci]
Haddock's named chunk feature was not used correctly in this case,
as it cannot export only parts of a Haddock top level comment.
As such, it was removed and replaced by a message informing the end-
user to browse the source code for detailed information.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AvailTC was not be upheld for explicit export module
export lists when the module contains associated data families.
module A (module A) where
class C a where { data T a }
instance C () where { data T () = D }
Used to (incorrectly) report avails as `[C{C, T;}, T{D;}]`. Note that
although `T` is exported, the avail where it is the parent does _not_
list it as its first element. This avail is now correctly listed as
`[C{C, T;}, T{T, D;}]`.
This was induces a [crash in Haddock][0].
See #16077.
[0]: https://github.com/haskell/haddock/issues/979
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following a succession of refactorings of the type checker,
culminating in the patch
Make a smart mkAppTyM
we have got rid of mkNakedAppTy etc. And that in turn
meant that the tcm_smart field of the generic TyCoMapper
(in Type.hs) was entirely unused. It was always set to True.
So this patch just gets rid of it completely. Less code,
less complexity, and more efficient because fewer higher-order
function calls. Everyone wins.
No change in behaviour; this does not cure any bugs!
|
| | |
|
| |
|
|
|
|
|
|
| |
The 4 main testsuites in Haddock don't have many dependencies, but are
regularly broken in small ways by changes to the GHC AST or the GHC API.
The main gotcha is that we'll have to make sure that `haddock-test` and
the test suite don't add modules without modifying this test. Then again,
if that happens, the test will fail and someone will noticed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Smaller than word size integers must be promoted to word size
when passed on the stack. While on little endian systems we can
get away with writing a small integer to a word size stack slot
and read it as a word ignoring the upper bits, on big endian
systems a small integer write ends up in the most significant
bits and a word size read that ignores the upper bits delivers
a random value.
On little endian systems a smaller than word size write to
the stack might be more efficient but that decision is
system specific and should be done as an optimization in the
respective backends.
Fixes #16258
|
