- Jan 14, 2024
- Jul 05, 2023
-
-
Numerous tests make use of CUSKs (complete user-supplied kinds), a legacy feature scheduled for deprecation. In order to proceed with the said deprecation, the tests have been updated to use SAKS instead (standalone kind signatures). This also allows us to remove the Haskell2010 language pragmas that were added in 115cd3c8 to work around the lack of CUSKs in GHC2021.
-
- Sep 13, 2022
-
-
- Jun 06, 2022
-
-
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
-
- Nov 17, 2021
-
-
Since 8.10, when formatting a pattern match warning, we'd case split on a wildcard match such as ```hs foo :: [a] -> [a] foo [] = [] foo xs = ys where (_, ys@(_:_)) = splitAt 0 xs -- Pattern match(es) are non-exhaustive -- In a pattern binding: -- Patterns not matched: -- ([], []) -- ((_:_), []) ``` But that's quite verbose and distracts from which part of the pattern was actually the inexhaustive one. We'd prefer a wildcard for the first pair component here, like it used to be in GHC 8.8. On the other hand, case splitting is pretty handy for `-XEmptyCase` to know the different constructors we could've matched on: ```hs f :: Bool -> () f x = case x of {} -- Pattern match(es) are non-exhaustive -- In a pattern binding: -- Patterns not matched: -- False -- True ``` The solution is to communicate that we want a top-level case split to `generateInhabitingPatterns` for `-XEmptyCase`, which is exactly what this patch arranges. Details in `Note [Case split inhabiting patterns]`. Fixes #20642.
-
- Mar 14, 2021
-
-
This patch makes `guessConLikeUnivTyArgsFromResTy` consider required Thetas of PatSynCons, by treating them as Wanted constraints to be discharged with the constraints from the Nabla's TyState and saying "does not match the match type" if the Wanted constraints are unsoluble. It calls out into a new function `GHC.Tc.Solver.tcCheckWanteds` to do so. In pushing the failure logic around call sites of `initTcDsForSolver` inside it by panicking, I realised that there was a bunch of dead code surrounding `pmTopMoraliseType`: I was successfully able to delete the `NoChange` data constructor of `TopNormaliseTypeResult`. The details are in `Note [Matching against a ConLike result type]` and `Note [Instantiating a ConLike]. The regression test is in `T19475`. It's pretty much a fork of `T14422` at the moment. Co-authored-by:Cale Gibbard <cgibbard@gmail.com>
-
- Mar 10, 2021
-
-
- Mar 05, 2021
-
-
Commit 2a942285 dramatically simplified the implementation and improved the performance of COMPLETE sets while making them applicable in more scenarios at the same time. But it turned out that there was a change in semantics that (to me unexpectedly) broke users' expectations (see #14422): They relied on the "type signature" of a COMPLETE pragma to restrict the scrutinee types of a pattern match for which they are applicable. This patch brings back that filtering, so the semantics is the same as it was in GHC 9.0. See the updated Note [Implementation of COMPLETE pragmas]. There are a few testsuite output changes (`completesig13`, `T14422`) which assert this change. Co-authored-by:
Sebastian Graf <sebastian.graf@kit.edu>
-
- Jan 17, 2021
-
-
The `expect_broken` of `T14059b` expected outdated output. But #14059 has long been fixed, so we this commit accepts the new output and marks the test as unbroken.
-
Consider `T18960`: ```hs pattern P :: a -> a pattern P x = x {-# COMPLETE P :: () #-} foo :: () foo = case () of P _ -> () ``` We know about the match variable of the case match that it is equal to `()`. After the match on `P`, we still know it's equal to `()` (positive info), but also that it can't be `P` (negative info). By the `COMPLETE` pragma, we know that implies that the refinement type of the match variable is empty after the `P` case. But in the PmCheck solver, we assumed that "has positive info" means "is not empty", thus assuming we could omit a costly inhabitation test. Which is wrong, as we saw above. A bit of a complication arises because the "has positive info" spared us from doing a lot of inhabitation tests in `T17836b`. So we keep that check, but give it a lower priority than the check for dirty variables that requires us doing an inhabitation test. Needless to say: This doesn't impact soundness of the checker at all, it just implements a better trade-off between efficiency and precision. Fixes #18960. Metric Decrease: T17836
-
- Nov 19, 2020
-
-
In order to avoid confusion as in #18932, we display the type of the match variables in the non-exhaustiveness warning, e.g. ``` T18932.hs:14:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘g’: Patterns of type ‘T a’, ‘T a’, ‘T a’ not matched: (MkT2 _) (MkT1 _) (MkT1 _) (MkT2 _) (MkT1 _) (MkT2 _) (MkT2 _) (MkT2 _) (MkT1 _) (MkT2 _) (MkT2 _) (MkT2 _) ... | 14 | g (MkT1 x) (MkT1 _) (MkT1 _) = x | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` It also allows us to omit the type signature on wildcard matches which we previously showed in only some situations, particularly `-XEmptyCase`. Fixes #18932.
-
- Sep 12, 2020
-
-
By not attaching COMPLETE pragmas with a particular TyCon and instead assume that every COMPLETE pragma is applicable everywhere, we can drastically simplify the logic that tries to initialise available COMPLETE sets of a variable during the pattern-match checking process, as well as fixing a few bugs. Of course, we have to make sure not to report any of the ill-typed/unrelated COMPLETE sets, which came up in a few regression tests. In doing so, we fix #17207, #18277 and #14422. There was a metric decrease in #18478 by ~20%. Metric Decrease: T18478
-
- Nov 05, 2019
-
-
We can handle non-void constraints since !1733, so we can now express the strictness of `-XEmptyCase` just by adding a non-void constraint to the initial Uncovered set. For `case x of {}` we thus check that the Uncovered set `{ x | x /~ ⊥ }` is non-empty. This is conceptually simpler than the plan outlined in #17376, because it talks to the oracle directly. In order for this patch to pass the testsuite, I had to fix handling of newtypes in the pattern-match checker (#17248). Since we use a different code path (well, the main code path) for `-XEmptyCase` now, we apparently also handle #13717 correctly. There's also some dead code that we can get rid off now. `provideEvidence` has been updated to provide output more in line with the old logic, which used `inhabitationCandidates` under the hood. A consequence of the shift away from the `UncoveredPatterns` type is that we don't report reduced type families for empty case matches, because the pretty printer is pure and only knows the match variable's type. Fixes #13717, #17248, #17386
-
- Sep 16, 2019
-
-
Previously, we had an elaborate mechanism for selecting the warnings to generate in the presence of different `COMPLETE` matching groups that, albeit finely-tuned, produced wrong results from an end user's perspective in some cases (#13363). The underlying issue is that at the point where the `ConVar` case has to commit to a particular `COMPLETE` group, there's not enough information to do so and the status quo was to just enumerate all possible complete sets nondeterministically. The `getResult` function would then pick the outcome according to metrics defined in accordance to the user's guide. But crucially, it lacked knowledge about the order in which affected clauses appear, leading to the surprising behavior in #13363. In !1010 we taught the term oracle to reason about literal values a variable can certainly not take on. This MR extends that idea to `ConLike`s and thereby fixes #13363: Instead of committing to a particular `COMPLETE` group in the `ConVar` case, we now split off the matching constructor incrementally and record the newly covered case as a refutable shape in the oracle. Whenever the set of refutable shapes covers any `COMPLETE` set, the oracle recognises vacuosity of the uncovered set. This patch goes a step further: Since at this point the information in value abstractions is merely a cut down representation of what the oracle knows, value abstractions degenerate to a single `Id`, the semantics of which is determined by the oracle state `Delta`. Value vectors become lists of `[Id]` given meaning to by a single `Delta`, value set abstractions (of which the uncovered set is an instance) correspond to a union of `Delta`s which instantiate the same `[Id]` (akin to models of formula). Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149 ------------------------- Metric Decrease: ManyAlternatives T11195 -------------------------
-
- Jun 14, 2018
-
-
Vladislav Zavialov authored
Summary: Implement the "Embrace Type :: Type" GHC proposal, .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the -XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with -XDataKinds but not -XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and -XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in -XTypeInType into the -XPolyKinds and -XDataKinds extensions. * Introduce a new extension -XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748
-
- Jun 03, 2018
-
-
Ryan Scott authored
As observed in #14059 (starting at comment 5), the error messages surrounding a program involving GADTs and a `COMPLETE` set became worse between 8.2 and 8.4. The culprit was a new validity check in 8.4 which filters out `COMPLETE` set candidates if a return type of any conlike in the set doesn't match the type of the scrutinee. However, this check was too conservative, since it removed perfectly valid `COMPLETE` sets that contained GADT constructors, which quite often have return types that don't match the type of a scrutinee. To fix this, I adopted the most straightforward possible solution of only performing this validity check on //pattern synonym// constructors, not //data// constructors. Note that this does not fix #14059 entirely, but instead simply fixes a particular buglet that was discovered in that ticket. Test Plan: make test TEST=T14059 Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14059 Differential Revision: https://phabricator.haskell.org/D4752
-
- Sep 21, 2017
-
-
Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3997
-
- Apr 11, 2017
-
-
Gabor Greif authored
-
- Mar 03, 2017
-
-
Ben Gamari authored
-
It relied on an orphan COMPLETE pragma, so was broken by commit fce3d37c. Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3266
-
Ben Gamari authored
It's unclear why this didn't show up in my initial local validation. Oh well.
-
- Jan 26, 2017
-
-
Matthew Pickering authoredThis patch adds a new pragma so that users can specify `COMPLETE` sets of `ConLike`s in order to sate the pattern match checker. A function which matches on all the patterns in a complete grouping will not cause the exhaustiveness checker to emit warnings. ``` pattern P :: () pattern P = () {-# COMPLETE P #-} foo P = () ``` This example would previously have caused the checker to warn that all cases were not matched even though matching on `P` is sufficient to make `foo` covering. With the addition of the pragma, the compiler will recognise that matching on `P` alone is enough and not emit any warnings. Reviewers: goldfire, gkaracha, alanz, austin, bgamari Reviewed By: alanz Subscribers: lelf, nomeata, gkaracha, thomie Differential Revision: https://phabricator.haskell.org/D2669 GHC Trac Issues: #8779
-
