[Git][ghc/ghc][wip/T18021] 7 commits: gitlab-ci: Fix copy-paste error

Ryan Scott gitlab at gitlab.haskell.org
Tue Dec 8 21:07:18 UTC 2020 


Ryan Scott pushed to branch wip/T18021 at Glasgow Haskell Compiler / GHC


Commits:
e0b08c5f by Ben Gamari at 2020-12-03T13:01:47-05:00
gitlab-ci: Fix copy-paste error

Also be more consistent in quoting.

- - - - -
33ec3a06 by Ben Gamari at 2020-12-03T23:11:31-05:00
gitlab-ci: Run linters through ci.sh

Ensuring that the right toolchain is used.

- - - - -
4a437bc1 by Shayne Fletcher at 2020-12-05T09:06:38-05:00
Fix bad span calculations of post qualified imports

- - - - -
8fac4b93 by Ben Gamari at 2020-12-05T09:07:13-05:00
testsuite: Add a test for #18923

- - - - -
62ed6957 by Simon Peyton Jones at 2020-12-08T15:31:41-05:00
Fix kind inference for data types. Again.

This patch fixes several aspects of kind inference for data type
declarations, especially data /instance/ declarations

Specifically

1. In kcConDecls/kcConDecl make it clear that the tc_res_kind argument
   is only used in the H98 case; and in that case there is no result
   kind signature; and hence no need for the disgusting splitPiTys in
   kcConDecls (now thankfully gone).

   The GADT case is a bit different to before, and much nicer.
   This is what fixes #18891.

   See Note [kcConDecls: kind-checking data type decls]

2. Do not look at the constructor decls of a data/newtype instance
   in tcDataFamInstanceHeader. See GHC.Tc.TyCl.Instance
   Note [Kind inference for data family instances].  This was a
   new realisation that arose when doing (1)

   This causes a few knock-on effects in the tests suite, because
   we require more information than before in the instance /header/.

   New user-manual material about this in "Kind inference in data type
   declarations" and "Kind inference for data/newtype instance
   declarations".

3. Minor improvement in kcTyClDecl, combining GADT and H98 cases

4. Fix #14111 and #8707 by allowing the header of a data instance
   to affect kind inferece for the the data constructor signatures;
   as described at length in Note [GADT return types] in GHC.Tc.TyCl

   This led to a modest refactoring of the arguments (and argument
   order) of tcConDecl/tcConDecls.

5. Fix #19000 by inverting the sense of the test in new_locs
   in GHC.Tc.Solver.Canonical.canDecomposableTyConAppOK.

- - - - -
0abe3ddf by Adam Sandberg Ericsson at 2020-12-08T15:32:19-05:00
hadrian: build the _l and _thr_l rts flavours in the develN flavours

The ghc binary requires the eventlog rts since
fc644b1a643128041cfec25db84e417851e28bab

- - - - -
6d129f4c by Ryan Scott at 2020-12-08T16:06:23-05:00
Reject dodgy scoping in associated family instance RHSes

Commit e63518f5d6a93be111f9108c0990a1162f88d615 tried to push all of the logic
of detecting out-of-scope type variables on the RHSes of associated type family
instances to `GHC.Tc.Validity` by deleting a similar check in the renamer.
Unfortunately, this commit went a little too far, as there are some corner
cases that `GHC.Tc.Validity` doesn't detect. Consider this example:

```hs
class C a where
  data D a

instance forall a. C Int where
  data instance D Int = MkD a
```

If this program isn't rejected by the time it reaches the typechecker, then
GHC will believe the `a` in `MkD a` is existentially quantified and accept it.
This is almost surely not what the user wants! The simplest way to reject
programs like this is to restore the old validity check in the renamer
(search for `improperly_scoped` in `rnFamEqn`).

Note that this is technically a breaking change, since the program in the
`polykinds/T9574` test case (which previously compiled) will now be rejected:

```hs
instance Funct ('KProxy :: KProxy o) where
    type Codomain 'KProxy = NatTr (Proxy :: o -> *)
```

This is because the `o` on the RHS will now be rejected for being out of scope.
Luckily, this is simple to repair:

```hs
instance Funct ('KProxy :: KProxy o) where
    type Codomain ('KProxy @o) = NatTr (Proxy :: o -> *)
```

All of the discussion is now a part of the revamped
`Note [Renaming associated types]` in `GHC.Rename.Module`.

A different design would be to make associated type family instances have
completely separate scoping from the parent instance declaration, much like
how associated type family default declarations work today. See the discussion
beginning at https://gitlab.haskell.org/ghc/ghc/-/issues/18021#note_265729 for
more on this point. This, however, would break even more programs that are
accepted today and likely warrants a GHC proposal before going forward. In the
meantime, this patch fixes the issue described in #18021 in the least invasive
way possible. There are programs that are accepted today that will no longer
be accepted after this patch, but they are arguably pathological programs, and
they are simple to repair.

Fixes #18021.

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Parser.y
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Solver/Canonical.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/TyCl/Instance.hs
- docs/users_guide/9.2.1-notes.rst
- docs/users_guide/exts/poly_kinds.rst
- hadrian/src/Settings/Flavours/Development.hs
- testsuite/tests/dependent/should_fail/T13780a.stderr
- testsuite/tests/deriving/should_compile/T11416.hs
- testsuite/tests/deriving/should_compile/T9359.hs
- + testsuite/tests/gadt/SynDataRec.hs
- testsuite/tests/gadt/all.T
- + testsuite/tests/indexed-types/should_compile/T14111.hs
- + testsuite/tests/indexed-types/should_compile/T8707.hs
- testsuite/tests/indexed-types/should_compile/all.T
- testsuite/tests/indexed-types/should_fail/T5515.stderr
- testsuite/tests/indexed-types/should_fail/T8368.stderr
- testsuite/tests/indexed-types/should_fail/T8368a.stderr
- testsuite/tests/module/all.T
- + testsuite/tests/module/mod185.hs
- + testsuite/tests/module/mod185.stderr
- testsuite/tests/patsyn/should_fail/T15685.stderr
- + testsuite/tests/perf/compiler/T18923.hs
- testsuite/tests/perf/compiler/all.T
- testsuite/tests/polykinds/T13659.stderr


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/96ad03e1e9a417ee9201f89968a760da0fb2d683...6d129f4ce2eb9ba0baeade6c825816dc45d92ad7

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/96ad03e1e9a417ee9201f89968a760da0fb2d683...6d129f4ce2eb9ba0baeade6c825816dc45d92ad7
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20201208/de138c31/attachment.html>

More information about the ghc-commits mailing list