[Git][ghc/ghc][wip/T17656] 7 commits: User guide minor typo

Ben Gamari gitlab at gitlab.haskell.org
Fri Dec 18 02:01:09 UTC 2020 


Ben Gamari pushed to branch wip/T17656 at Glasgow Haskell Compiler / GHC


Commits:
80df2edd by David Eichmann at 2020-12-17T13:55:21-05:00
User guide minor typo

[ci skip]

- - - - -
09f28390 by nineonine at 2020-12-17T13:55:59-05:00
Force module recompilation if '*' prefix was used to load modules in ghci (#8042)

Usually pre-compiled code is preferred to be loaded in ghci if available, which means
that if we try to load module with '*' prefix and compilation artifacts are available
on disc (.o and .hi files) or the source code was untouched, the driver would think
no recompilation is required. Therefore, we need to force recompilation so that desired
byte-code is generated and loaded. Forcing in this case should be ok, since this is what
happens for interpreted code anyways when reloading modules.

- - - - -
b1178cbc by Ryan Scott at 2020-12-17T13:56:35-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.

- - - - -
cf8ab4a6 by Tom Ellis at 2020-12-17T13:57:12-05:00
submodule update: containers and stm

Needed for https://gitlab.haskell.org/ghc/ghc/-/issues/15656 as it
stops the packages triggering incomplete-uni-patterns and
incomplete-record-updates

- - - - -
df7c7faa by Richard Eisenberg at 2020-12-17T13:57:48-05:00
Unfortunate dirty hack to overcome #18998.

See commentary in tcCheckUsage.

Close #18998.

Test case: typecheck/should_compile/T18998

- - - - -
659fcb14 by Sylvain Henry at 2020-12-17T13:58:30-05:00
Fix project version for ProjectVersionMunged (fix #19058)

- - - - -
ac5b1742 by Simon Peyton Jones at 2020-12-17T21:01:07-05:00
Kill floatEqualities completely

This patch delivers on #17656, by entirel killing off the complex
floatEqualities mechanism.  Previously, floatEqualities would float an
equality out of an implication, so that it could be solved at an outer
level. But now we simply do unification in-place, without floating the
constraint, relying on level numbers to determine untouchability.

There are a number of important new Notes:

* GHC.Tc.Utils.Unify Note [Unification preconditions]
  describes the preconditions for unification, including both
  skolem-escape and touchability.

* GHC.Tc.Solver.Interact Note [Solve by unification]
  describes what we do when we do unify

* GHC.Tc.Solver.Monad Note [The Unification Level Flag]
  describes how we control solver iteration under this new scheme

* GHC.Tc.Solver.Monad Note [Tracking Given equalities]
  describes how we track when we have Given equalities

* GHC.Tc.Types.Constraint Note [HasGivenEqs]
  is a new explanation of the ic_given_eqs field of an implication

A big raft of subtle Notes in Solver, concerning floatEqualities,
disappears.

Main code changes:

* GHC.Tc.Solver.floatEqualities disappears entirely

* GHC.Tc.Solver.Monad: new fields in InertCans, inert_given_eq_lvl
  and inert_given_eq, updated by updateGivenEqs
  See Note [Tracking Given equalities].

* In exchange for updateGivenEqa, GHC.Tc.Solver.Monad.getHasGivenEqs
  is much simpler and more efficient

* I found I could kill of metaTyVarUpdateOK entirely

One test case T14683 showed a 5.1% decrease in compile-time
allocation; and T5631 was down 2.2%. Other changes were small.

Metric Decrease:
    T14683
    T5631

- - - - -


30 changed files:

- .gitlab/linters/check-version-number.sh
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Runtime/Heap/Inspect.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Gen/App.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/Solver/Canonical.hs
- compiler/GHC/Tc/Solver/Interact.hs
- compiler/GHC/Tc/Solver/Monad.hs
- compiler/GHC/Tc/Types/Constraint.hs
- compiler/GHC/Tc/Utils/Env.hs
- compiler/GHC/Tc/Utils/Monad.hs
- compiler/GHC/Tc/Utils/TcMType.hs
- compiler/GHC/Tc/Utils/TcType.hs
- compiler/GHC/Tc/Utils/Unify.hs
- configure.ac
- docs/users_guide/9.2.1-notes.rst
- docs/users_guide/runtime_control.rst
- libraries/containers
- libraries/stm
- testsuite/tests/ghci.debugger/scripts/break012.stdout
- + testsuite/tests/ghci/scripts/T8042recomp.script
- + testsuite/tests/ghci/scripts/T8042recomp.stdout
- testsuite/tests/ghci/scripts/all.T
- testsuite/tests/indexed-types/should_fail/T5515.stderr
- testsuite/tests/partial-sigs/should_compile/T10403.stderr
- testsuite/tests/partial-sigs/should_compile/T14715.stderr
- testsuite/tests/partial-sigs/should_fail/ScopedNamedWildcardsBad.stderr


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/79c6c01a7540a78ec6e492f86f84c8fec5f57bd1...ac5b1742f3390c95ade4ada822b000ab3e182c3f

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/79c6c01a7540a78ec6e492f86f84c8fec5f57bd1...ac5b1742f3390c95ade4ada822b000ab3e182c3f
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/20201217/0a978d5b/attachment-0001.html>

More information about the ghc-commits mailing list