| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
This ensures that all testsuite way names given to `omit_ways`,
`only_ways`, etc. are known ways.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `makefile_test` and `run_command` tests could easily end up
in a situation where they wouldn't be run if the user used the
`only_ways` modifier. The reason is to build the set of a ways to run
the test in we first start with a candidate set determined by the test
type (e.g. `makefile_test`, `compile_run`, etc.) and then filter that
set with the constraints given by the test's modifiers.
`makefile_test` and `run_command` tests' candidate sets were simply
`{normal}`, and consequently most uses of `only_ways` would result in
the test being never run.
To avoid this we rather use all ways as the candidate sets for these
test types. This may result in a few more testcases than we would like
(given that some `run_command` tests are insensitive to way) but this
can be fixed by adding modifiers and we would much rather run too many
tests than too few.
This fixes #16042 and a number of other tests afflicted by the same issue.
However, there were a few cases that required special attention:
* `T14028` is currently failing and is therefore marked as broken due
to #17300
* `T-signals-child` is fragile in the `threaded1` and `threaded2` ways
(tracked in #17307)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces three new modules:
- basicTypes/Predicate.hs describes predicates, moving
this logic out of Type. Predicates don't really exist
in Core, and so don't belong in Type.
- typecheck/TcOrigin.hs describes the origin of constraints
and types. It was easy to remove from other modules and
can often be imported instead of other, scarier modules.
- typecheck/Constraint.hs describes constraints as used in
the solver. It is taken from TcRnTypes.
No work other than module splitting is in this patch.
This is the first step toward homogeneous equality, which will
rely more strongly on predicates. And homogeneous equality is the
next step toward a dependently typed core language.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #17343 we saw that we didn't handle the pattern guard `!_ <-
undefined` correctly: The `undefined` was never evaluated. Indeed,
elaboration failed to insert the invisible type aruments to `undefined`.
So `undefined` was trivially a normal-form and in turn never entered.
The problem is that we used to infer a sigma-type for the RHS of the
guard, the leading qualifiers of which will never be useful in a pattern
match situation. Hence we infer a rho-type now.
Fixes #17343.
|
|
|
|
|
|
|
|
| |
This is a test for the current algorithm of GHCi command name resolution.
I add this test in preparation for updating GHCi command name resolution.
For the current algorithm, see https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ghci.html#the-ghci-files
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #17355 occurred because the control flow for
`TcValidity.check_valid_inst_head` was structured in such a way that
whenever it checked a special, built-in class (like `Generic` or
`HasField`), it would skip the most important check of all:
`checkValidTypePats`, which rejects nonsense like this:
```hs
instance Generic (forall a. a)
```
This fixes the issue by carving out `checkValidTypePats` from
`check_valid_inst_head` so that `checkValidTypePats` is always
invoked. `check_valid_inst_head` has also been renamed to
`check_special_inst_head` to reflect its new purpose of _only_
checking for instances headed by special classes.
Fixes #17355.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Statements can change the basic block in which instructions
are placed during instruction selection.
We have to keep track of this switch of the current basic block
as we need this information in order to properly update the CFG.
This commit implements this change and fixes #17334.
We do so by having stmtToInstr return the new block id
if a statement changed the basic block.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC has a wonderful-but-delicate mechanism for building recursive
dictionaries by adding a goal to the "solved dictionaries" before
solving the sub-goals. See Note [Solved dictionaries] in TcSMonad
Ticket #17267 showed that if you use this mechanism for local
/quantified/ constraints you can get a loop -- or even unsafe
coerce. This patch fixes the bug.
Specifically
* Make TcSMonad.addSolvedDict be conditional on using a
/top level/ instance, not a quantified one.
* Moreover, we /also/ don't want to add a solved dict
for equalities (a~b).
* Add lots more comments to Note [Solved dictionaries]
to explain the above cryptic stuff.
* Extend InstanceWhat to identify those strange built-in
equality instances.
A couple of other things along the way
* Delete the unused Type.isIPPred_maybe.
* Stop making addSolvedDict conditional on not being an
impolicit parameter. This comes from way back. But
it's irrelevant now because IP dicts are never solved
via an instance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC is suposed to uphold the principle that an /inferred/ type
for a let-binding should obey the rules for that module. E.g.
we should only accept an inferred higher rank type if we have
RankNTypes on.
But we were failing to check this: TcValidity.checkValidType
allowed arbitrary rank for inferred types.
This patch fixes the bug. It might in principle cause some breakage,
but if so that's good: the user should add RankNTypes and/or a
manual signature. (And almost every package has explicit user
signatures for all top-level things anyway.) Let's see.
Fixes #17213.
Metric Decrease:
T10370
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #17339 was caused by using a slightly different version of
`newDFunName` for derived instances that, confusingly enough, did not
take all arguments to the class into account when generating the
`DFun` name. I cannot think of any good reason for doing this, so
this patch uses `newDFunName` uniformly for both derived instances
and manually written instances alike.
Fixes #17339.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CI job fails with:
+++ rts/T13676.run/T13676.run.stderr.normalised 2019-10-09 12:27:56.000000000 -0700
@@ -0,0 +1,4 @@
+dyld: Library not loaded: @rpath/libHShaskeline-0.7.5.0-ghc8.9.0.20191009.dylib
+ Referenced from: /Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib/bin/ghc
+ Reason: image not found
+*** Exception: readCreateProcess: '/Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib/bin/ghc' '-B/Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib' '-e' ''/''$'/'' == '/''/x0024'/''' +RTS '-tT13676.t' (exit -6): failed
Unable to reproduce locally.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simon realised that the simple language composed of let bindings, bang
patterns and flat constructor patterns is enough to capture the
semantics of the source pattern language that are important for
pattern-match checking. Well, given that the Oracle is smart enough to
connect the dots in this less informationally dense form, which it is
now.
So we transform `translatePat` to return a list of `PmGrd`s relative to
an incoming match variable. `pmCheck` then trivially translates each of
the `PmGrd`s into constraints that the oracle understands.
Since we pass in the match variable, we incidentally fix #15884
(coverage checks for view patterns) through an interaction with !1746.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you derive an instance like this:
```hs
deriving <...> instance Foo C
```
And the data constructors for `C` aren't in scope, then
`doDerivInstErrorChecks1` throws an error. Moreover, it will
_only_ throw an error if `<...>` is either `stock` or `newtype`.
This is because the code that the `anyclass` or `via` strategies
would generate would not require the use of the data constructors
for `C`.
However, `doDerivInstErrorChecks1` has another purpose. If you
write this:
```hs
import M (C(MkC1, ..., MkCn))
deriving <...> instance Foo C
```
Then `doDerivInstErrorChecks1` will call `addUsedDataCons` on
`MkC1` through `MkCn` to ensure that `-Wunused-imports` does not
complain about them. However, `doDerivInstErrorChecks1` was doing
this for _every_ deriving strategy, which mean that if `<...>` were
`anyclass` or `via`, then the warning about `MkC1` through `MkCn`
being unused would be suppressed!
The fix is simple enough: only call `addUsedDataCons` when the
strategy is `stock` or `newtype`, just like the other code paths
in `doDerivInstErrorChecks1`.
Fixes #17324.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The vanilla COMPLETE set is attached to the representation TyCon of a
data family instance, whereas the user-defined COMPLETE sets are
attached to the parent data family TyCon itself.
Previously, we weren't trying particularly hard to get back to the
representation TyCon to the parent data family TyCon, resulting in bugs
like #17207. Now we should do much better.
Fixes the original issue in #17207, but I found another related bug that
isn't so easy to fix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, all constraints from all top-level groups (as
separated by top-level splices) were lumped together and solved
at the end. This could leak metavariables to TH, though, and
that's bad. This patch solves each group's constraints before
running the next group's splice.
Naturally, we now report fewer errors in some cases.
One nice benefit is that this also fixes #11680, but in a much
simpler way than the original fix for that ticket. Admittedly,
the error messages degrade just a bit from the fix from #11680
(previously, we informed users about variables that will be
brought into scope below a top-level splice, and now we just
report an out-of-scope error), but the amount of complexity
required throughout GHC to get that error was just not worth it.
This patch thus reverts much of
f93c9517a2c6e158e4a5c5bc7a3d3f88cb4ed119.
Fixes #16980
Test cases: th/T16980{,a}
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, newtype constructors are not marked as used when they are
accessed under the hood by uses of `coerce`, as described in #10347.
This fixes #10347 by co-opting the `tcg_keep` field of `TcGblEnv`
to track uses of newtype constructors in the `Coercible` solver.
See `Note [Tracking unused binding and imports]` in `TcRnTypes`.
Since #10347 is fixed, I was able to simplify the code in `TcDeriv`
slightly, as the hack described in
`Note [Newtype deriving and unused constructors]`
is no longer necessary.
|
|
|
|
|
|
|
|
|
|
| |
By introducing a `CoreMap Id` to the term oracle, we can represent
syntactically equivalent expressions by the same `Id`. Combine that with
`CoreOpt.simpleCoreExpr` and it might even catch non-trivial semantic
equalities.
Unfortunately due to scoping issues, this will not solve #17208 for
view patterns yet.
|
|
|
|
|
|
|
|
|
|
|
|
| |
As described in the new Note [LLVM Configuration] in SysTools, we now
load llvm-targets and llvm-passes lazily to avoid the overhead of doing
so when -fllvm isn't used (also known as "the common case").
Noticed in #17003.
Metric Decrease:
T12234
T12150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among other uses, `coreFlattenTyFamApp` is used by Core Lint as a
part of its check to ensure that each type family axiom reduces
according to the way it is defined in the source code. Unfortunately,
the logic that `coreFlattenTyFamApp` uses to flatten type family
applications disagreed with the logic in `TcFlatten`, which caused
it to spuriously complain this program:
```hs
type family Param :: Type -> Type
type family LookupParam (a :: Type) :: Type where
LookupParam (f Char) = Bool
LookupParam x = Int
foo :: LookupParam (Param ())
foo = 42
```
This is because `coreFlattenTyFamApp` tries to flatten the `Param ()`
in `LookupParam (Param ())` to `alpha` (where `alpha` is a flattening
skolem), and GHC is unable to conclude that `alpha` is apart from
`f Char`. This patch spruces up `coreFlattenTyFamApp` so that it
instead flattens `Param ()` to `alpha ()`, which GHC _can_ know for
sure is apart from `f Char`. See
`Note [Flatten], wrinkle 3` in `FamInstEnv`.
|
|
|
|
|
| |
If a main module doesn't contain a header, we omit the check whether the main module is exported.
With this patch GHC, GHCi and runghc use the same code.
|
| |
|
|
|
|
| |
Zeros heap memory after gc freed it.
|
|
|
|
| |
See #16205.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also changes the way we handle empty lists, simplifying
them somewhat. See Note [Empty lists]. Previously, we had to
special-case empty lists in the type-checker. Now no more!
Finally, this patch improves some documentation around the ir_inst
field used in the type-checker.
This breaks a test case, but I really think the problem is #17251,
not really related to this patch.
Test case: typecheck/should_compile/T13680
|
|
|
|
| |
This is a good convenience for testing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simon writes:
Currently we check for a type arg rather than isTyCoArg. This in turn
makes INLINE things look bigger than they should be, and stops them
being inlined into boring contexts when they perfectly well could be.
E.g.
f x = g <refl> x
{-# INLINE g #-}
... (map (f x) xs) ...
The context is boring, so don't inline unconditionally. But f's RHS is
no bigger than its call, provided you realise that the coercion argument
is ultimately cost-free.
This happens in practice for $WHRefl. It's not a big deal: at most it
means we have an extra function call overhead. But it's untidy, and
actually worse than what happens without an INLINE pragma.
Fixes #17182
This makes 0.0% change in nofib binary sizes.
|
|
|
|
|
|
|
|
|
| |
In his paper "Warnings for Pattern Matching", Luke Maranget describes
three series in his appendix for which GHC's pattern match checker
scaled very badly. We mostly avoid this now with !1752. This commit adds
regression tests for each of the series.
Fixes #17264.
|
|
|
|
|
| |
Adds regression tests for tickets #17207, #17208, #17215, #17216,
#17218, #17219, #17248
|
|
|
|
| |
See #17256.
|
|
|
|
|
|
|
|
|
|
| |
Currently, there are no testcases for GHCi `:doc` command.
Perhaps because it was experimental. And it could be changed in the future.
But `:doc` command is already useful, so I add a minimal regression test
to keep current behavior.
See also 85309a3cda for implementation of `:doc` command.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`pmcheck` used to call `refineToAltCon` which would refine the knowledge
we had about a variable by equating it to a `ConLike` application.
Since we weren't particularly smart about this in the Check module, we
simply freshened the constructors existential and term binders utimately
through a call to `mkOneConFull`.
But that instantiation is unnecessary for when we match against a
concrete pattern! The pattern will already have fresh binders and field
types. So we don't call `refineToAltCon` from `Check` anymore.
Subsequently, we can simplify a couple of call sites and functions in
`PmOracle`. Also implementing `computeCovered` becomes viable and we
don't have to live with the hack that was `addVarPatVecCt` anymore.
A side-effect of not indirectly calling `mkOneConFull` anymore is that
we don't generate the proper strict argument field constraints anymore.
Instead we now desugar ConPatOuts as if they had bangs on their strict
fields. This implies that `PmVar` now carries a `HsImplBang` that we
need to respect by a (somewhat ephemeral) non-void check. We fix #17234
in doing so.
|
|
|
|
|
| |
Due to #16087. This drops the previous explicit list of broken tests and rather
encompasses the entire set of tests since they all appear to be broken.
|
|
|
|
| |
As noted in #17256.
|
|
|
|
|
| |
Due to #16361. Note that I'm leaving out threaded2 since it's not clear
whether the single crash in that way was due to other causes.
|
|
|
|
| |
As described in #17247.
|
| |
|
|
|
|
|
|
|
|
|
| |
Basically do what we currently only do for -XEmptyCase in other cases
where adding the type signature won't distract from pattern
matches in other positions.
We use the precedence to guide us, equating "need to parenthesise" with
"too much noise".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This resolves #16876 by making the explicit use of `-fbyte-code`
prevent code that enables `UnboxedTuples` or `UnboxedSums` from
automatically compiling to object code. This allows for a nice
middle ground where most code that enables `UnboxedTuples`/-`Sums`
will still benefit from automatically enabling `-fobject-code`, but
allows power users who wish to avoid this behavior in certain corner
cases (such as `lens`, whose use case is documented in #16876) to do
so.
Along the way, I did a little cleanup of the relevant code and
documentation:
* `enableCodeGenForUnboxedTuples` was only checking for the presence
of `UnboxedTuples`, but `UnboxedSums` has the same complications.
I fixed this and renamed the function to
`enableCodeGenForUnboxedTuplesOrSums`.
* I amended the users' guide with a discussion of these issues.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst
With this patch, a type constructor can now be given an explicit
standalone kind signature:
{-# LANGUAGE StandaloneKindSignatures #-}
type Functor :: (Type -> Type) -> Constraint
class Functor f where
fmap :: (a -> b) -> f a -> f b
This is a replacement for CUSKs (complete user-specified
kind signatures), which are now scheduled for deprecation.
User-facing changes
-------------------
* A new extension flag has been added, -XStandaloneKindSignatures, which
implies -XNoCUSKs.
* There is a new syntactic construct, a standalone kind signature:
type <name> :: <kind>
Declarations of data types, classes, data families, type families, and
type synonyms may be accompanied by a standalone kind signature.
* A standalone kind signature enables polymorphic recursion in types,
just like a function type signature enables polymorphic recursion in
terms. This obviates the need for CUSKs.
* TemplateHaskell AST has been extended with 'KiSigD' to represent
standalone kind signatures.
* GHCi :info command now prints the kind signature of type constructors:
ghci> :info Functor
type Functor :: (Type -> Type) -> Constraint
...
Limitations
-----------
* 'forall'-bound type variables of a standalone kind signature do not
scope over the declaration body, even if the -XScopedTypeVariables is
enabled. See #16635 and #16734.
* Wildcards are not allowed in standalone kind signatures, as partial
signatures do not allow for polymorphic recursion.
* Associated types may not be given an explicit standalone kind
signature. Instead, they are assumed to have a CUSK if the parent class
has a standalone kind signature and regardless of the -XCUSKs flag.
* Standalone kind signatures do not support multiple names at the moment:
type T1, T2 :: Type -> Type -- rejected
type T1 = Maybe
type T2 = Either String
See #16754.
* Creative use of equality constraints in standalone kind signatures may
lead to GHC panics:
type C :: forall (a :: Type) -> a ~ Int => Constraint
class C a where
f :: C a => a -> Int
See #16758.
Implementation notes
--------------------
* The heart of this patch is the 'kcDeclHeader' function, which is used to
kind-check a declaration header against its standalone kind signature.
It does so in two rounds:
1. check user-written binders
2. instantiate invisible binders a la 'checkExpectedKind'
* 'kcTyClGroup' now partitions declarations into declarations with a
standalone kind signature or a CUSK (kinded_decls) and declarations
without either (kindless_decls):
* 'kinded_decls' are kind-checked with 'checkInitialKinds'
* 'kindless_decls' are kind-checked with 'getInitialKinds'
* DerivInfo has been extended with a new field:
di_scoped_tvs :: ![(Name,TyVar)]
These variables must be added to the context in case the deriving clause
references tcTyConScopedTyVars. See #16731.
|
|
|
|
|
| |
The `Ix` class seems rather orthogonal to its original home in
`GHC.Arr`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces a new flag `-fmax-pmcheck-deltas` to achieve that. Deprecates
the old `-fmax-pmcheck-iter` mechanism in favor of this new flag.
From the user's guide:
Pattern match checking can be exponential in some cases. This limit makes sure
we scale polynomially in the number of patterns, by forgetting refined
information gained from a partially successful match. For example, when
matching `x` against `Just 4`, we split each incoming matching model into two
sub-models: One where `x` is not `Nothing` and one where `x` is `Just y` but
`y` is not `4`. When the number of incoming models exceeds the limit, we
continue checking the next clause with the original, unrefined model.
This also retires the incredibly hard to understand "maximum number of
refinements" mechanism, because the current mechanism is more general
and should catch the same exponential cases like PrelRules at the same
time.
-------------------------
Metric Decrease:
T11822
-------------------------
|
|
|
|
|
|
| |
Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause
a warning when no explicit deriving strategy is in use. This change adds
an enable/suppress flag for it.
|
|
|
|
| |
Due to #16555.
|
|
|
|
|
| |
Add a new optional failure handling for upsweep which continues
the compilation on other modules if any of them has errors.
|