| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
RyanGlScott observed in https://github.com/haskell/haddock/issues/1030
that running Haddock tests in GHC's testsuite left some `.hi` files
around in `utils/haddock`. This should fix that problem.
|
|
|
|
|
| |
Otherwise these tests break spuriously when core libraries are compiled
with source notes.
|
|
|
|
| |
Python's split() function is used to split on all white space.
|
|
|
|
|
|
|
|
|
|
| |
The following previously fatal lexer errors are now non-fatal:
* errors about enabling `LambdaCase`
* errors about enabling `NumericUnderscores`
* errors about having valid characters in primitive strings
See #16270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements GHC proposal 35
(https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
by adding the ability to write kinds with
visible dependent quantification (VDQ).
Most of the work for supporting VDQ was actually done _before_ this
patch. That is, GHC has been able to reason about kinds with VDQ for
some time, but it lacked the ability to let programmers directly
write these kinds in the source syntax. This patch is primarly about
exposing this ability, by:
* Changing `HsForAllTy` to add an additional field of type
`ForallVisFlag` to distinguish between invisible `forall`s (i.e,
with dots) and visible `forall`s (i.e., with arrows)
* Changing `Parser.y` accordingly
The rest of the patch mostly concerns adding validity checking to
ensure that VDQ is never used in the type of a term (as permitting
this would require full-spectrum dependent types). This is
accomplished by:
* Adding a `vdqAllowed` predicate to `TcValidity`.
* Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
that only splits invisible `forall`s. This function is used in
certain places (e.g., in instance declarations) to ensure that GHC
doesn't try to split visible `forall`s (e.g., if it tried splitting
`instance forall a -> Show (Blah a)`, then GHC would mistakenly
allow that declaration!)
This also updates Template Haskell by introducing a new `ForallVisT`
constructor to `Type`.
Fixes #16326. Also fixes #15658 by documenting this feature in the
users' guide.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds trace messages that include the processes name and as such
make debugging and following the communication easier.
It also adds a note regarding the fwd*Call proxy-communication logic
between the proxy and the slave.
The proxy will now also poll for 60s to wait for the remote iserv
to come up. (Alternatively you can start the remote process
beforehand; and just have iserv-proxy connect to it)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hie002 is a performance test that used to fail unpredictably:
max_bytes_used Decrease from x86_64-linux-deb9-debug baseline @ HEAD~2:
Expected hie002 (normal) max_bytes_used: 1190923992.0 +/-20%
Lower bound hie002 (normal) max_bytes_used: 952739193
Upper bound hie002 (normal) max_bytes_used: 1429108791
Actual hie002 (normal) max_bytes_used: 726270784
Deviation hie002 (normal) max_bytes_used: -39.0 %
peak_megabytes_allocated Decrease from x86_64-linux-deb9-debug baseline @ HEAD~2:
Expected hie002 (normal) peak_megabytes_allocated: 2538.0 +/-20%
Lower bound hie002 (normal) peak_megabytes_allocated: 2030
Upper bound hie002 (normal) peak_megabytes_allocated: 3046
Actual hie002 (normal) peak_megabytes_allocated: 1587
Deviation hie002 (normal) peak_megabytes_allocated: -37.5 %
*** unexpected stat test failure for hie002(normal)
'max_bytes_used' and 'peak_megabytes_allocated' are too unstable without careful
control of the runtime configuration. We fix this by using a more predictable
metric, 'bytes allocated'.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the work stealing queue a load-load-barrier is required to ensure
that a read of queue data cannot be reordered before a read of the
bottom pointer into the queue.
The added load-load-barrier ensures that the ordering of writes enforced
at the end of `pushWSDeque` is also respected in the order of reads in
`stealWSDeque_`. In other words, when reading `q->bottom` we want to make
sure that we see the updates to `q->elements`.
Fixes #13633
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
Fixes Trac #16334, Trac #16315
With this patch, scoping rules for type and kind variables have been
unified: kind variables no longer receieve special treatment. This
simplifies both the language and the implementation.
User-facing changes
-------------------
* Kind variables are no longer implicitly quantified when an explicit
forall is used:
p :: Proxy (a :: k) -- still accepted
p :: forall k a. Proxy (a :: k) -- still accepted
p :: forall a. Proxy (a :: k) -- no longer accepted
In other words, now we adhere to the "forall-or-nothing" rule more
strictly.
Related function: RnTypes.rnImplicitBndrs
* The -Wimplicit-kind-vars warning has been deprecated.
* Kind variables are no longer implicitly quantified in constructor
declarations:
data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted
data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted
Related function: RnTypes.extractRdrKindSigVars
* Implicitly quantified kind variables are no longer put in front of
other variables:
f :: Proxy (a :: k) -> Proxy (b :: j)
f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order
f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order
This is a breaking change for users of TypeApplications. Note that
we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
See "Ordering of specified variables" in the User's Guide.
Related function: RnTypes.rnImplicitBndrs
* In type synonyms and type family equations, free variables on the RHS
are no longer implicitly quantified unless used in an outermost kind
annotation:
type T = Just (Nothing :: Maybe a) -- no longer accepted
type T = Just Nothing :: Maybe (Maybe a) -- still accepted
The latter form is a workaround due to temporary lack of an explicit
quantification method. Ideally, we would write something along these
lines:
type T @a = Just (Nothing :: Maybe a)
Related function: RnTypes.extractHsTyRdrTyVarsKindVars
* Named wildcards in kinds are fixed (Trac #16334):
x :: (Int :: _t) -- this compiles, infers (_t ~ Type)
Related function: RnTypes.partition_nwcs
Implementation notes
--------------------
* One of the key changes is the removal of FKTV in RnTypes:
- data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName]
- , fktv_tys :: [Located RdrName] }
+ type FreeKiTyVars = [Located RdrName]
We used to keep track of type and kind variables separately, but
now that they are on equal footing when it comes to scoping, we
can put them in the same list.
* extract_lty and family are no longer parametrized by TypeOrKind,
as we now do not distinguish kind variables from type variables.
* PatSynExPE and the related Note [Pattern synonym existentials do not scope]
have been removed (Trac #16315). With no implicit kind quantification,
we can no longer trigger the error.
* reportFloatingKvs and the related Note [Free-floating kind vars]
have been removed. With no implicit kind quantification,
we can no longer trigger the error.
|
|
|
|
| |
14586f5d removed this by accident.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use "touch -r" to set modification timestamps, which leads to precision loss
on Darwin. For example,
before: 2019-02-25 01:11:23.807627350 +0300
after: 2019-02-25 01:11:23.807627000 +0300
^^^
This means we can't trick GHCi into thinking the file hasn't been changed by
restoring its old timestamp, as we cannot faithfully restore all digits.
The solution is to nullify the insignificant digits before the first :load
|
|
|
|
| |
See Trac #15072, Trac #16349, Trac #16350
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
For some reason gitlab is not reporting these as failures in CI. It's
not clear to me why as the junit output looks fine.
Fixes #16112 and #16113
They were fixed by 682783828275cca5fd8bf5be5b52054c75e0e22c
|
|
|
|
| |
and CI results."
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes us fail fast in TcSimplify.solveLocalEqualities,
and in TcHsType.tc_hs_sig_type, if there are insoluble constraints.
Previously we ploughed on even if there were insoluble constraints,
leading to a cascade of hard-to-understand type errors. Failing
eagerly is much better; hence a lot of testsuite error message
changes. Eg if we have
f :: [Maybe] -> blah
f xs = e
then trying typecheck 'f x = e' with an utterly bogus type
is just asking for trouble.
I can't quite remember what provoked me to make this change,
but I think the error messages are notably improved, by
removing confusing clutter and focusing on the real error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch finally delivers on Trac #15952. Specifically
* Completely remove Note [The tcType invariant], along with
its complicated consequences (IT1-IT6).
* Replace Note [The well-kinded type invariant] with:
Note [The Purely Kinded Type Invariant (PKTI)]
* Instead, establish the (PKTI) in TcHsType.tcInferApps,
by using a new function mkAppTyM when building a type
application. See Note [mkAppTyM].
* As a result we can remove the delicate mkNakedXX functions
entirely. Specifically, mkNakedCastTy retained lots of
extremly delicate Refl coercions which just cluttered
everything up, and(worse) were very vulnerable to being
silently eliminated by (say) substTy. This led to a
succession of bug reports.
The result is noticeably simpler to explain, simpler
to code, and Richard and I are much more confident that
it is correct.
It does not actually fix any bugs, but it brings us closer.
E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite
do so. However, it makes it much easier to fix.
I also did a raft of other minor refactorings:
* Use tcTypeKind consistently in the type checker
* Rename tcInstTyBinders to tcInvisibleTyBinders,
and refactor it a bit
* Refactor tcEqType, pickyEqType, tcEqTypeVis
Simpler, probably more efficient.
* Make zonkTcType zonk TcTyCons, at least if they have
any free unification variables -- see zonk_tc_tycon
in TcMType.zonkTcTypeMapper.
Not zonking these TcTyCons was actually a bug before.
* Simplify try_to_reduce_no_cache in TcFlatten (a lot)
* Combine checkExpectedKind and checkExpectedKindX.
And then combine the invisible-binder instantation code
Much simpler now.
* Fix a little bug in TcMType.skolemiseQuantifiedTyVar.
I'm not sure how I came across this originally.
* Fix a little bug in TyCoRep.isUnliftedRuntimeRep
(the ASSERT was over-zealous). Again I'm not certain
how I encountered this.
* Add a missing solveLocalEqualities in
TcHsType.tcHsPartialSigType.
I came across this when trying to get level numbers
right.
|
|
|
|
|
|
|
|
|
| |
-Wredundant-record-wildcards warns when a .. pattern binds no variables.
-Wunused-record-wildcards warns when none of the variables bound by a ..
pattern are used.
These flags are enabled by `-Wall`.
|
| |
|
|
|
|
|
|
|
|
| |
Implements GHC proposal 43, adding a `liftTyped` method to the `Lift` typeclass.
This also adds some documentation to `TExp`, describing typed splices and their
advantages over their untyped counterparts.
Resolves #14671.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHCi's `:info` command was pretty-printing Haskell98-style data types
with explicit return kinds if the return kind wasn't `Type`. This
leads to bizarre output like this:
```
λ> :i (##)
data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##)
-- Defined in ‘GHC.Prim’
```
Or, with unlifted newtypes:
```
λ> newtype T = MkT Int#
λ> :i T
newtype T :: TYPE 'IntRep = MkT Int#
-- Defined at <interactive>:5:1
```
The solution is simple: just delete one part from `IfaceSyn` where
GHC mistakenly pretty-prints the return kinds for non-GADTs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was an awful lot of zipping going on in
canDecomposableTyConAppOK, and one of the lists being zipped
was too short, causing the result to be too short. Easily
fixed.
Also fixes #16204 and #16225
test case: typecheck/should_compile/T16188
typecheck/should_compile/T16204[ab]
typecheck/should_fail/T16204c
typecheck/should_compile/T16225
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug fixes three problems related to `Proxy#`/`proxy#`:
1. Reifying it with TH claims that the `Proxy#` type constructor has
two arguments, but that ought to be one for consistency with
TH's treatment for other primitive type constructors like `(->)`.
This was fixed by just returning the number of
`tyConVisibleTyVars` instead of using `tyConArity` (which includes
invisible arguments).
2. The role of `Proxy#`'s visible argument was hard-coded as nominal.
Easily fixed by changing it to phantom.
3. The visibility of `proxy#`'s kind argument was specified, which
is different from the `Proxy` constructor (which treats it as
inferred). Some minor refactoring in `proxyHashId` fixed ths up.
Along the way, I had to introduce a `mkSpecForAllTy` function, so
I did some related Haddock cleanup in `Type`, where that function
lives.
|
| |
|
|
|
|
| |
See #16193.
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the JUnit output more useful as now we also report the
stdout/stderr in the message which can be used to quickly identify why a
test is failing without downloading the log.
This also introduces TestResult,
previously we were simply passing around tuples, making things the
implementation rather difficult to follow and harder to extend.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression caused by #15471 where splicing in a trivial
program such as `[|| return () ||]` would fail as the dictionary for
`return` would never get bound in the module containing the splice.
Arguably this is symptomatic of a major problem affecting TTH where we
serialise renamed asts and then retype check them. The reference to the
dictionary should be fully determined at the quote site so that splicing
doesn't have to solve any implicits at all. It's a coincidence this
works due to coherence but see #15863 and #15865 for examples where
things do go very wrong.
Fixes #16195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the alternate layout rule is activated via a pragma, it injects
tokens for { and } to make sure that the source is parsed properly.
But it injects ITocurly and ITccurly, rather than their virtual
counterparts ITvocurly and ITvccurly.
This causes problems for ghc-exactprint, which tries to print these.
Likewise, any injected ITsemi should have a zero-width SrcSpan.
Test case (the existing T13087.hs)
{-# LANGUAGE AlternativeLayoutRule #-}
{-# LANGUAGE LambdaCase #-}
isOne :: Int -> Bool
isOne = \case 1 -> True
_ -> False
main = return ()
Closes #16279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch from https://phabricator.haskell.org/D4865 introduces
go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix
= do { warnStarBndr l
; let name = mkOccName tcClsName (if isUni then "★" else "*")
; return (cL l (Unqual name), acc, fix, ann) }
which discards the parens annotations belonging to the HsParTy.
Updates haddock submodule
Closes #16265
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the code
type family F1 (a :: k) (f :: k -> Type) :: Type where
F1 @Peano a f = T @Peano f a
the API annotation for the first @ is not attached to a SourceSpan in
the ParsedSource
Closes #16236
|