[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 4 commits: Broaden the in-scope sets for liftEnvSubst and composeTCvSubst

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Wed Oct 26 11:36:33 UTC 2022



Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
f7bfb40c by Ryan Scott at 2022-10-26T00:01:24-04:00
Broaden the in-scope sets for liftEnvSubst and composeTCvSubst

This patch fixes two distinct (but closely related) buglets that were uncovered
in #22235:

* `liftEnvSubst` used an empty in-scope set, which was not wide enough to cover
  the variables in the range of the substitution. This patch fixes this by
  populating the in-scope set from the free variables in the range of the
  substitution.
* `composeTCvSubst` applied the first substitution argument to the range of the
  second substitution argument, but the first substitution's in-scope set was
  not wide enough to cover the range of the second substutition. We similarly
  fix this issue in this patch by widening the first substitution's in-scope set
  before applying it.

Fixes #22235.

- - - - -
0270cc54 by Vladislav Zavialov at 2022-10-26T00:02:01-04:00
Introduce TcRnWithHsDocContext (#22346)

Before this patch, GHC used withHsDocContext to attach an HsDocContext
to an error message:

	addErr $ mkTcRnUnknownMessage $ mkPlainError noHints (withHsDocContext ctxt msg)

The problem with this approach is that it only works with
TcRnUnknownMessage. But could we attach an HsDocContext to a
structured error message in a generic way? This patch solves
the problem by introducing a new constructor to TcRnMessage:

	data TcRnMessage where
	  ...
	  TcRnWithHsDocContext :: !HsDocContext -> !TcRnMessage -> TcRnMessage
	  ...

- - - - -
9ab31f42 by Sylvain Henry at 2022-10-26T09:32:20+02:00
Testsuite: more precise test options

Necessary for newer cross-compiling backends (JS, Wasm) that don't
support TH yet.

- - - - -
c06a4787 by Vladislav Zavialov at 2022-10-26T07:36:21-04:00
Use TcRnVDQInTermType in noNestedForallsContextsErr (#20115)

When faced with VDQ in the type of a term, GHC generates the following
error message:

	Illegal visible, dependent quantification in the type of a term
	(GHC does not yet support this)

Prior to this patch, there were two ways this message could have been
generated and represented:

	1. with the dedicated constructor TcRnVDQInTermType
	    (see check_type in GHC.Tc.Validity)
	2. with the transitional constructor TcRnUnknownMessage
	    (see noNestedForallsContextsErr in GHC.Rename.Utils)

Not only this led to duplication of code generating the final SDoc,
it also made it tricky to track the origin of the error message.

This patch fixes the problem by using TcRnVDQInTermType exclusively.

- - - - -


30 changed files:

- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Rename/Utils.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Validity.hs
- compiler/GHC/Types/Error/Codes.hs
- testsuite/driver/testlib.py
- testsuite/tests/annotations/should_fail/all.T
- testsuite/tests/annotations/should_run/all.T
- testsuite/tests/backpack/should_run/all.T
- testsuite/tests/codeGen/should_compile/T17904.hs
- testsuite/tests/codeGen/should_run/T20137/all.T
- testsuite/tests/codeGen/should_run/T20735/all.T
- testsuite/tests/codeGen/should_run/all.T
- testsuite/tests/corelint/all.T
- testsuite/tests/dependent/should_compile/all.T
- testsuite/tests/dependent/should_fail/T16326_Fail6.stderr
- testsuite/tests/dependent/should_fail/T16326_Fail8.stderr
- testsuite/tests/dependent/should_fail/T18271.stderr
- testsuite/tests/deriving/should_compile/all.T
- testsuite/tests/driver/T20604/all.T
- testsuite/tests/driver/T7835/all.T
- testsuite/tests/driver/all.T
- testsuite/tests/driver/fat-iface/all.T
- testsuite/tests/driver/multipleHomeUnits/all.T
- testsuite/tests/driver/multipleHomeUnits/o-dir/all.T


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8a05d955c4b0e510a64582ce98ff13afd51215ff...c06a478782db9175b3588f352721e0e8fb6ed57c

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8a05d955c4b0e510a64582ce98ff13afd51215ff...c06a478782db9175b3588f352721e0e8fb6ed57c
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/20221026/c851a5a9/attachment.html>


More information about the ghc-commits mailing list