[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: gitlab-ci: Verify that Hadrian builds with Stack
Marge Bot
gitlab at gitlab.haskell.org
Wed Oct 14 08:13:56 UTC 2020
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
0fc1cb54 by Ben Gamari at 2020-10-14T03:42:50-04:00
gitlab-ci: Verify that Hadrian builds with Stack
As noted in #18726, this regularly breaks. Let's test it.
Note that we don't actually perform a build of GHC itself; we merely
test that the Hadrian executable builds and works (by invoking `hadrian
--version`).
- - - - -
39a725fe by Ben Gamari at 2020-10-14T04:13:39-04:00
Bump LLVM version to 10.0
Fixes #18267.
- - - - -
606822ab by Ryan Scott at 2020-10-14T04:13:42-04:00
Make DataKinds the sole arbiter of kind-level literals (and friends)
Previously, the use of kind-level literals, promoted tuples,
and promoted lists required enabling both `DataKinds` and
`PolyKinds`. This made sense back in a `TypeInType` world, but not so
much now that `TypeInType`'s role has been superseded. Nowadays,
`PolyKinds` only controls kind polymorphism, so let's make `DataKinds`
the thing that controls the other aspects of `TypeInType`, which include
literals, promoted tuples and promoted lists.
There are some other things that overzealously required `PolyKinds`,
which this patch fixes as well:
* Previously, using constraints in kinds (e.g., `data T :: () -> Type`)
required `PolyKinds`, despite the fact that this is orthogonal to kind
polymorphism. This now requires `DataKinds` instead.
* Previously, using kind annotations in kinds
(e.g., `data T :: (Type :: Type) -> Type`) required both `KindSignatures`
and `PolyKinds`. This doesn't make much sense, so it only requires
`KindSignatures` now.
Fixes #18831.
- - - - -
56dd839b by Vladislav Zavialov at 2020-10-14T04:13:43-04:00
Remove "Operator sections" from docs/users_guide/bugs.rst
The issue described in that section was fixed by
2b89ca5b850b4097447cc4908cbb0631011ce979
- - - - -
6070787f by Vladislav Zavialov at 2020-10-14T04:13:43-04:00
Fix PostfixOperators (#18151)
This fixes a regression introduced in 2b89ca5b850b4097447cc4908cbb0631011ce979
See the new T18151x test case.
- - - - -
15 changed files:
- .gitlab-ci.yml
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/Rename/HsType.hs
- configure.ac
- docs/users_guide/bugs.rst
- docs/users_guide/exts/data_kinds.rst
- docs/users_guide/exts/poly_kinds.rst
- hadrian/build-stack
- hadrian/build-stack.bat
- + testsuite/tests/deSugar/should_run/T18151x.hs
- + testsuite/tests/deSugar/should_run/T18151x.stdout
- testsuite/tests/deSugar/should_run/all.T
- testsuite/tests/th/T17688b.hs
- + testsuite/tests/typecheck/should_compile/T18831.hs
- testsuite/tests/typecheck/should_compile/all.T
Changes:
=====================================
.gitlab-ci.yml
=====================================
@@ -233,6 +233,17 @@ lint-release-changelogs:
tags:
- x86_64-linux
+# Verify that Hadrian builds with stack. Note that we don't actually perform a
+# build of GHC itself; we merely test that the Hadrian executable builds and
+# works (by invoking `hadrian --version`).
+stack-hadrian-build:
+ extends: .validate-linux-hadrian
+ stage: build
+ script:
+ - .gitlab/ci.sh setup
+ - .gitlab/ci.sh configure
+ - hadrian/build-stack --version
+
validate-x86_64-linux-deb9-hadrian:
extends: .validate-linux-hadrian
needs: [hadrian-ghc-in-ghci]
@@ -827,6 +838,9 @@ validate-x86_64-linux-fedora27:
stage: full-build
image: "registry.gitlab.haskell.org/ghc/ci-images/x86_64-linux-fedora27:$DOCKER_REV"
variables:
+ # LLVM 10 is not available for Fedora27
+ LLC: /bin/false
+ OPT: /bin/false
TEST_ENV: "x86_64-linux-fedora27"
BIN_DIST_PREP_TAR_COMP: "ghc-x86_64-fedora27-linux.tar.xz"
cache:
=====================================
compiler/GHC/HsToCore/Expr.hs
=====================================
@@ -70,6 +70,8 @@ import GHC.Utils.Panic
import GHC.Core.PatSyn
import Control.Monad
+import qualified GHC.LanguageExtensions as LangExt
+
{-
************************************************************************
* *
@@ -347,7 +349,11 @@ converting to core it must become a CO.
Note [Desugaring operator sections]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-At first it looks as if we can convert
+Desugaring left sections with -XPostfixOperators is straightforward: convert
+(expr `op`) to (op expr).
+
+Without -XPostfixOperators it's a bit more tricky. At first it looks as if we
+can convert
(expr `op`)
@@ -398,6 +404,13 @@ dsExpr e@(OpApp _ e1 op e2)
-- See Note [Desugaring operator sections].
-- N.B. this also must handle postfix operator sections due to -XPostfixOperators.
dsExpr e@(SectionL _ expr op) = do
+ postfix_operators <- xoptM LangExt.PostfixOperators
+ if postfix_operators then
+ -- Desugar (e !) to ((!) e)
+ do { op' <- dsLExpr op
+ ; dsWhenNoErrs (dsLExprNoLP expr) $ \expr' ->
+ mkCoreAppDs (text "sectionl" <+> ppr expr) op' expr' }
+ else do
core_op <- dsLExpr op
x_core <- dsLExpr expr
case splitFunTys (exprType core_op) of
=====================================
compiler/GHC/Rename/HsType.hs
=====================================
@@ -441,9 +441,9 @@ sites. This is less precise, but more accurate.
rnHsType is here because we call it from loadInstDecl, and I didn't
want a gratuitous knot.
-Note [QualTy in kinds]
+Note [HsQualTy in kinds]
~~~~~~~~~~~~~~~~~~~~~~
-I was wondering whether QualTy could occur only at TypeLevel. But no,
+I was wondering whether HsQualTy could occur only at TypeLevel. But no,
we can have a qualified type in a kind too. Here is an example:
type family F a where
@@ -466,9 +466,9 @@ suitable message:
Expected kind: G Bool
Actual kind: F Bool
-However: in a kind, the constraints in the QualTy must all be
+However: in a kind, the constraints in the HsQualTy must all be
equalities; or at least, any kinds with a class constraint are
-uninhabited.
+uninhabited. See Note [Constraints in kinds] in GHC.Core.TyCo.Rep.
-}
data RnTyKiEnv
@@ -574,7 +574,9 @@ rnHsTyKi env ty@(HsForAllTy { hst_tele = tele, hst_body = tau })
, fvs) } }
rnHsTyKi env ty@(HsQualTy { hst_ctxt = lctxt, hst_body = tau })
- = do { checkPolyKinds env ty -- See Note [QualTy in kinds]
+ = do { data_kinds <- xoptM LangExt.DataKinds -- See Note [HsQualTy in kinds]
+ ; when (not data_kinds && isRnKindLevel env)
+ (addErr (dataKindsErr env ty))
; (ctxt', fvs1) <- rnTyKiContext env lctxt
; (tau', fvs2) <- rnLHsTyKi env tau
; return (HsQualTy { hst_xqual = noExtField, hst_ctxt = ctxt'
@@ -636,9 +638,8 @@ rnHsTyKi env listTy@(HsListTy _ ty)
; (ty', fvs) <- rnLHsTyKi env ty
; return (HsListTy noExtField ty', fvs) }
-rnHsTyKi env t@(HsKindSig _ ty k)
- = do { checkPolyKinds env t
- ; kind_sigs_ok <- xoptM LangExt.KindSignatures
+rnHsTyKi env (HsKindSig _ ty k)
+ = do { kind_sigs_ok <- xoptM LangExt.KindSignatures
; unless kind_sigs_ok (badKindSigErr (rtke_ctxt env) ty)
; (ty', lhs_fvs) <- rnLHsTyKi env ty
; (k', sig_fvs) <- rnLHsTyKi (env { rtke_level = KindLevel }) k
@@ -665,7 +666,6 @@ rnHsTyKi env tyLit@(HsTyLit _ t)
= do { data_kinds <- xoptM LangExt.DataKinds
; unless data_kinds (addErr (dataKindsErr env tyLit))
; when (negLit t) (addErr negLitErr)
- ; checkPolyKinds env tyLit
; return (HsTyLit noExtField t, emptyFVs) }
where
negLit (HsStrTy _ _) = False
@@ -705,15 +705,13 @@ rnHsTyKi _ (XHsType (NHsCoreTy ty))
-- but I don't think it matters
rnHsTyKi env ty@(HsExplicitListTy _ ip tys)
- = do { checkPolyKinds env ty
- ; data_kinds <- xoptM LangExt.DataKinds
+ = do { data_kinds <- xoptM LangExt.DataKinds
; unless data_kinds (addErr (dataKindsErr env ty))
; (tys', fvs) <- mapFvRn (rnLHsTyKi env) tys
; return (HsExplicitListTy noExtField ip tys', fvs) }
rnHsTyKi env ty@(HsExplicitTupleTy _ tys)
- = do { checkPolyKinds env ty
- ; data_kinds <- xoptM LangExt.DataKinds
+ = do { data_kinds <- xoptM LangExt.DataKinds
; unless data_kinds (addErr (dataKindsErr env ty))
; (tys', fvs) <- mapFvRn (rnLHsTyKi env) tys
; return (HsExplicitTupleTy noExtField tys', fvs) }
=====================================
configure.ac
=====================================
@@ -715,7 +715,7 @@ AC_SUBST(InstallNameToolCmd)
# tools we are looking for. In the past, GHC supported a number of
# versions of LLVM simultaneously, but that stopped working around
# 3.5/3.6 release of LLVM.
-LlvmVersion=9
+LlvmVersion=10
AC_SUBST([LlvmVersion])
sUPPORTED_LLVM_VERSION=$(echo \($LlvmVersion\) | sed 's/\./,/')
AC_DEFINE_UNQUOTED([sUPPORTED_LLVM_VERSION], ${sUPPORTED_LLVM_VERSION}, [The supported LLVM version number])
=====================================
docs/users_guide/bugs.rst
=====================================
@@ -438,31 +438,6 @@ The Foreign Function Interface
single: hs_init
single: hs_exit
-.. _infelicities-operator-sections:
-
-Operator sections
-^^^^^^^^^^^^^^^^^
-
-The Haskell Report demands that, for infix operators ``%``, the following
-identities hold:
-
-::
-
- (% expr) = \x -> x % expr
- (expr %) = \x -> expr % x
-
-However, the second law is violated in the presence of undefined operators,
-
-::
-
- (%) = error "urk"
- (() %) `seq` () -- urk
- (\x -> () % x) `seq` () -- OK, result ()
-
-The operator section is treated like function application of an undefined
-function, while the lambda form is in WHNF that contains an application of an
-undefined function.
-
.. _haskell-98-2010-undefined:
GHC's interpretation of undefined behaviour in Haskell 98 and Haskell 2010
=====================================
docs/users_guide/exts/data_kinds.rst
=====================================
@@ -134,6 +134,12 @@ promotion quote and the data constructor: ::
type S = 'A' -- ERROR: looks like a character
type R = ' A' -- OK: promoted `A'`
+Type-level literals
+-------------------
+
+:extension:`DataKinds` enables the use of numeric and string literals at the
+type level. For more information, see :ref:`type-level-literals`.
+
.. _promoted-lists-and-tuples:
Promoted list and tuple types
@@ -207,4 +213,27 @@ above code is valid.
See also :ghc-ticket:`7347`.
+.. _constraints_in_kinds:
+
+Constraints in kinds
+--------------------
+
+Kinds can (with :extension:`DataKinds`) contain type constraints. However,
+only equality constraints are supported.
+
+Here is an example of a constrained kind: ::
+
+ type family IsTypeLit a where
+ IsTypeLit Nat = 'True
+ IsTypeLit Symbol = 'True
+ IsTypeLit a = 'False
+
+ data T :: forall a. (IsTypeLit a ~ 'True) => a -> Type where
+ MkNat :: T 42
+ MkSymbol :: T "Don't panic!"
+The declarations above are accepted. However, if we add ``MkOther :: T Int``,
+we get an error that the equality constraint is not satisfied; ``Int`` is
+not a type literal. Note that explicitly quantifying with ``forall a`` is
+necessary in order for ``T`` to typecheck
+(see :ref:`complete-kind-signatures`).
=====================================
docs/users_guide/exts/poly_kinds.rst
=====================================
@@ -787,29 +787,6 @@ distinction). GHC does not consider ``forall k. k -> Type`` and
``forall {k}. k -> Type`` to be equal at the kind level, and thus rejects
``Foo Proxy`` as ill-kinded.
-Constraints in kinds
---------------------
-
-As kinds and types are the same, kinds can (with :extension:`TypeInType`)
-contain type constraints. However, only equality constraints are supported.
-
-Here is an example of a constrained kind: ::
-
- type family IsTypeLit a where
- IsTypeLit Nat = 'True
- IsTypeLit Symbol = 'True
- IsTypeLit a = 'False
-
- data T :: forall a. (IsTypeLit a ~ 'True) => a -> Type where
- MkNat :: T 42
- MkSymbol :: T "Don't panic!"
-
-The declarations above are accepted. However, if we add ``MkOther :: T Int``,
-we get an error that the equality constraint is not satisfied; ``Int`` is
-not a type literal. Note that explicitly quantifying with ``forall a`` is
-necessary in order for ``T`` to typecheck
-(see :ref:`complete-kind-signatures`).
-
The kind ``Type``
-----------------
=====================================
hadrian/build-stack
=====================================
@@ -3,11 +3,13 @@
# Make sure that the script exits if Hadrian fails to build
set -euo pipefail
+STACK="${STACK:-stack}"
+
# Make sure Hadrian is up-to-date
cd hadrian
-stack build --no-library-profiling ${HADRIAN_NIX:+--nix}
+$STACK build --no-library-profiling ${HADRIAN_NIX:+--nix}
# Run Hadrian in the top-level GHC directory
-stack exec hadrian -- \
+$STACK exec hadrian -- \
--directory ".." \
"$@"
=====================================
hadrian/build-stack.bat
=====================================
@@ -3,5 +3,9 @@ setlocal
rem Change the current directory to the one containing this script
cd %~dp0
+if "%STACK%"=="" (
+ set STACK=stack
+)
+
rem Build and run Hadrian in GHC top directory forwarding additional user arguments
-stack run hadrian --cwd=.. -- %*
+%STACK% run hadrian --cwd=.. -- %*
=====================================
testsuite/tests/deSugar/should_run/T18151x.hs
=====================================
@@ -0,0 +1,17 @@
+{-# LANGUAGE PostfixOperators #-}
+
+import Control.Exception
+
+data MyException = MyE
+ deriving (Show)
+
+instance Exception MyException
+
+(#) :: Bool -> Bool -> Bool
+(#) = throw MyE
+
+main = do
+ r <- try (evaluate (seq (True #) ()))
+ case r of
+ Left MyE -> putStrLn "PostfixOperators ok"
+ Right () -> putStrLn "PostfixOperators broken"
=====================================
testsuite/tests/deSugar/should_run/T18151x.stdout
=====================================
@@ -0,0 +1 @@
+PostfixOperators ok
=====================================
testsuite/tests/deSugar/should_run/all.T
=====================================
@@ -65,6 +65,7 @@ test('T11747', normal, compile_and_run, ['-dcore-lint'])
test('T12595', normal, compile_and_run, [''])
test('T13285', normal, compile_and_run, [''])
test('T18151', normal, compile_and_run, [''])
+test('T18151x', normal, compile_and_run, [''])
test('T18172', [], ghci_script, ['T18172.script'])
test('DsDoExprFailMsg', exit_code(1), compile_and_run, [''])
=====================================
testsuite/tests/th/T17688b.hs
=====================================
@@ -1,3 +1,4 @@
+{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE StandaloneKindSignatures #-}
=====================================
testsuite/tests/typecheck/should_compile/T18831.hs
=====================================
@@ -0,0 +1,12 @@
+{-# LANGUAGE DataKinds #-}
+{-# LANGUAGE KindSignatures #-}
+module T18831 where
+
+import Data.Kind
+import Data.Proxy
+
+data T1 :: Proxy 0 -> Type
+data T2 :: () => Type
+data T3 :: (Type :: Type) -> Type
+data T4 :: Proxy '[Type,Type] -> Type
+data T5 :: Proxy '(Type,Type) -> Type
=====================================
testsuite/tests/typecheck/should_compile/all.T
=====================================
@@ -722,5 +722,6 @@ test('T18412', normal, compile, [''])
test('T18470', normal, compile, [''])
test('T18323', normal, compile, [''])
test('T18585', normal, compile, [''])
+test('T18831', normal, compile, [''])
test('T15942', normal, compile, [''])
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/45e52af724395be4f8aac3962f88b20a5aa4ad7b...6070787fee9f31569ed97f8ecf8a1de3294e6652
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/45e52af724395be4f8aac3962f88b20a5aa4ad7b...6070787fee9f31569ed97f8ecf8a1de3294e6652
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/20201014/f19d9936/attachment-0001.html>
More information about the ghc-commits
mailing list