June 2018 - ghc-tickets

[GHC] #15244: Ambiguity checks in QuantifiedConstraints
by GHC 11 Jun '18

11 Jun '18

#15244: Ambiguity checks in QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: | Owner: (none) bitwiseshiftleft | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Great work on QuantifiedConstraints! I'm giving it a whirl. With GHCI 8.5.20180605, I see somewhat annoying behavior around multiple instances. When two copies of the same (or equivalent) quantified constraint are in scope, they produce an error. I think this is about some kind of ambiguity check. {{{ {-# LANGUAGE QuantifiedConstraints, TypeFamilies #-} class (forall t . Eq (c t)) => Blah c -- Unquantified works foo :: (Eq (a t), Eq (b t), a ~ b) => a t -> b t -> Bool foo a b = a == b -- Works -- Two quantified instances fail with double ambiguity check errors bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool bar a b = a == b -- Minimal.hs:11:8: error: -- • Could not deduce (Eq (b t1)) -- from the context: (forall t1. Eq (a t1), forall t1. Eq (b t1), -- a ~ b) -- bound by the type signature for: -- bar :: forall (a :: * -> *) (b :: * -> *) t. -- (forall t1. Eq (a t1), forall t1. Eq (b t1), a ~ b) => -- a t -> b t -> Bool -- at Minimal.hs:11:8-78 -- • In the ambiguity check for ‘bar’ -- To defer the ambiguity check to use sites, enable AllowAmbiguousTypes -- In the type signature: -- bar :: (forall t. Eq (a t), forall t. Eq (b t), a ~ b) => -- a t -> b t -> Bool -- | -- 11 | bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool -- | -- [And then another copy of the same error] -- Two copies from superclass instances fail baz :: (Blah a, Blah b, a ~ b) => a t -> b t -> Bool baz a b = a == b -- Minimal.hs:34:11: error: -- • Could not deduce (Eq (b t)) arising from a use of ‘==’ -- from the context: (Blah a, Blah b, a ~ b) -- bound by the type signature for: -- baz :: forall (a :: * -> *) (b :: * -> *) t. -- (Blah a, Blah b, a ~ b) => -- a t -> b t -> Bool -- at Minimal.hs:33:1-52 -- • In the expression: a == b -- In an equation for ‘baz’: baz a b = a == b -- | -- 34 | baz a b = a == b -- | -- Two copies from superclass from same declaration also fail mugga :: (Blah a, Blah a) => a t -> a t -> Bool mugga a b = a == b -- • Could not deduce (Eq (a t)) arising from a use of ‘==’ -- from the context: (Blah a, Blah a) -- bound by the type signature for: -- mugga :: forall (a :: * -> *) t. -- (Blah a, Blah a) => -- a t -> a t -> Bool -- at Minimal.hs:50:1-47 -- • In the expression: a == b -- In an equation for ‘mugga’: mugga a b = a == b -- | -- 51 | mugga a b = a == b -- | -- One copy works quux :: (Blah a, a ~ b) => a t -> b t -> Bool quux a b = a == b -- Works }}} My program is similar to {{{Baz}}}. The constraints {{{Blah a}}} and {{{Blah b}}} are in scope from a pattern match, and I want to compare values of types {{{a t}}} and {{{b t}}} if they're the same type. So I get {{{a ~ b}}} from Typeable and try to compare them, but this doesn't work. I worked around the issue by writing a helper that only takes {{{(Blah a, Typeable a, Typeable b)}}}, so only one instance is in scope. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14737: Improve performance of Simplify.simplCast
by GHC 11 Jun '18

11 Jun '18

#14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #11735 #14683 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Splitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs] `simplCast` eats up more execution time than we think it should. From [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:10] > Something is clearly wrong with `Simplify.simplCast`. I think I know what it is. Given > {{{ > (fun |> co) @t1 @t2 ... @tn > }}} > we will call `pushCoTyArg` `n` times, and hence does `n` singleton substitutions, via the `n` calls to `piResultTy`. > > Solution: gather up those type arguments (easy) and define > {{{ > pushCoTyArgs :: Coercion -> [Type] -> Maybe ([Type], Coercion) > }}} And [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:41] > OK. I looked at `pushCoTyArg` and friends, and I have a very simple solution: just move the `isReflexiveCo` case in `addCoerce` (a local function within `Simplify.simplCast`) to the top. That should do it. Then `pushCoTyArg` is never called with a reflexive coercion, and so the `piResultTy` case won't happen. > > Now, `pushCoArgs` might still call `pushCoTyArg` with a reflexive coercion, but it can be taught not to as well: Have `pushCoArgs` return a `Maybe ([CoreArg], Maybe Coercion)` and `pushCoArg` return a `Maybe (CoreArg, Maybe Coercion)`. If the second return values are `Nothing`, that means that there is no cast (i.e., that the cast would have been reflexive). The only client of `pushCoArg(s)` is `exprIsConApp_maybe`, which simply omits a cast if `pushCoArgs` returns `Nothing`. Then, we never have to bother creating the reflexive coercions. > > This should be an easy win all around. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf)
by GHC 11 Jun '18

11 Jun '18

#15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -D__ARM_PCS_VFP -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.2 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux- gnueabihf; available targets: ["i386-unknown-windows","i686-unknown- windows","x86_64-unknown-windows","arm-unknown-linux-gnueabihf","armv6 -unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","armv7a-unknown-linux- gnueabi","i386-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown- linux-gnu","x86_64-unknown-linux","armv7-unknown-linux- androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=8.4.2-1&s… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances
by GHC 11 Jun '18

11 Jun '18

#13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Note that these are accepted: {{{#!hs class Foo (a :: TYPE ('TupleRep '[])) instance Foo (a :: TYPE ('TupleRep '[])) instance Foo (##) }}} But if you try to write these same instances using `DeriveAnyClass` and `StandaloneDeriving`, they'll be rejected for no good reason: {{{#!hs deriving instance Foo (a :: TYPE ('TupleRep '[])) {- • Can't make a derived instance of ‘Foo a’: The last argument of the instance must be a data or newtype application -} deriving instance Foo (##) {- • Can't make a derived instance of ‘Foo (# #)’: The last argument of the instance cannot be an unboxed tuple -} }}} The latter error is a vestige of #12512, and should be easy enough to rectify. The former error is a bit tricker to fix, since much of the code in `TcDeriv`/`TcDerivInfer` assumes that the type to which the class is applied to in the instead head is a datatype or newtype `TyCon`. It's apparent that this doesn't hold true in the presence of `DeriveAnyClass`, however, so that code should be refactored to reflect this. For practical reasons, however, it might be best to wait until after #12144 is fixed to tackle this one, since that splits out some logic in `TcDerivInfer` for `DeriveAnyClass` so as to make it no longer rely on the aforementioned `TyCon` invariant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15254: Cabal submodule bump is needed
by GHC 11 Jun '18

11 Jun '18

#15254: Cabal submodule bump is needed -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Cabal HEAD has recently been somewhat broken (https://github.com/haskell/cabal/issues/5318) and the current submodule is pointing to a buggy commit. This only manifests when installing `build- type: Custom` packages, because that uses the bad code from the bootstrap Cabal; `build-type: Simple` will use good code from the external `cabal- install` process. Please bump the Cabal submodule to fix this. I've verified that the observed problem (`happy` breaking) goes away when this is done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15254> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15256: GHCi check .ghci permission on WSL(Linux on Windows)
by GHC 10 Jun '18

10 Jun '18

#15256: GHCi check .ghci permission on WSL(Linux on Windows) --------------------------------+------------------------------------- Reporter: yongjoon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management. You can reproduce this problem from 8.2.2.~8.4.3 of GHC- WSL(https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl). I think GHCi of WSL would skip .ghci permission check. I used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem. However, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check. As you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777. Therefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console. P.S. Is there any bug-report place only for GHC-WSL? I couldn't find it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 10 Jun '18

10 Jun '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): Replying to [comment:27 Phyx-]: > I would change the first part to be more precise > > `Could not find module ‘Control.Monad.Random’` into something like `Could not load module ‘Control.Monad.Random’` since the message is a bit contradictory saying it couldn't find it yet it's part of a package it knows about. I toyed with this a bit, using "Could not load module" for hidden and unusable packages. It broke hundreds of tests, and I'm a bit uncomfortable with that. For that reason, I think it's best not to mess with that for now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15253: Add support for type-level integers
by GHC 10 Jun '18

10 Jun '18

#15253: Add support for type-level integers -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: compiler, | Operating System: Unknown/Multiple base | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Similar to GHC.TypeNats, it would be nice to see something like the following: {{{#!hs newtype TypeInt (n :: Nat) = TypeInt Integer class KnownInt (n :: k) where intSing :: TypeInt n intVal :: forall n proxy. KnownInt n => proxy n -> Integer intVal _ = case intSing :: TypeInt n of TypeInt x -> x intVal' :: forall n. KnownInt n => Proxy# n -> Integer intVal' _ = case intSing :: TypeInt n of TypeInt x -> x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14945: Compiling error related to rts/Stats.c
by GHC 10 Jun '18

10 Jun '18

#14945: Compiling error related to rts/Stats.c -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm receiving the following error message when compiling ghcHEAD: {{{ "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_p\" -optc-ffunction- sections -optc-fdata-sections -static -prof -eventlog -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Stats.c -o rts/dist/build/Stats.p_o rts/Stats.c: In function 'report_summary': rts/Stats.c:741:39: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'rc_cpu_ns'; did you mean 'rp_cpu_ns'? TimeToSecondsDbl(sum->rc_cpu_ns), ^ | 741 | TimeToSecondsDbl(sum->rc_cpu_ns), | ^ rts/Stats.c:29:39: error: note: in definition of macro 'TimeToSecondsDbl' #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) ^ | 29 | #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) | ^ rts/Stats.c:742:39: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'rc_elapsed_ns'; did you mean 'rp_elapsed_ns'? TimeToSecondsDbl(sum->rc_elapsed_ns)); ^ | 742 | TimeToSecondsDbl(sum->rc_elapsed_ns)); | ^ rts/Stats.c:29:39: error: note: in definition of macro 'TimeToSecondsDbl' #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) ^ | 29 | #define TimeToSecondsDbl(t) ((double)(t) / TIME_RESOLUTION) | ^ rts/Stats.c: In function 'report_machine_readable': rts/Stats.c:904:58: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'hp_cpu_ns'; did you mean 'rp_cpu_ns'? MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); ^ | 904 | MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); | ^ rts/Stats.c:867:62: error: note: in definition of macro 'MR_STAT' statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) ^~~~~ | 867 | statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) | ^ rts/Stats.c:904:36: error: note: in expansion of macro 'TimeToSecondsDbl' MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); ^~~~~~~~~~~~~~~~ | 904 | MR_STAT("hc_cpu_seconds", "f", TimeToSecondsDbl(sum->hp_cpu_ns)); | ^ rts/Stats.c:905:59: error: error: 'RTSSummaryStats {aka const struct RTSSummaryStats_}' has no member named 'hp_elapsed_ns'; did you mean 'rp_elapsed_ns'? MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); ^ | 905 | MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); | ^ rts/Stats.c:867:62: error: note: in definition of macro 'MR_STAT' statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) ^~~~~ | 867 | statsPrintf(" ,(\"" field_name "\", \"%" format "\")\n", value) | ^ rts/Stats.c:905:37: error: note: in expansion of macro 'TimeToSecondsDbl' MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); ^~~~~~~~~~~~~~~~ | 905 | MR_STAT("hc_wall_seconds", "f", TimeToSecondsDbl(sum->hp_elapsed_ns)); | ^ `cc' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [rts/ghc.mk:295: rts/dist/build/Stats.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 builder for '/nix/store/qvidsmhk6a1a1h96q85dx1dalgqgph4l- ghc-8.5.20180319.drv' failed with exit code 2 error: build of '/nix/store/qvidsmhk6a1a1h96q85dx1dalgqgph4l- ghc-8.5.20180319.drv' failed }}} I suspect it's related to the recent commit 2d4bda2e4ac68816baba0afab00da6f769ea75a7. Currently compiling the previous revision to confirm. Has anyone confirmed similar error in another environment? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11798: Recompiling with -fhpc flag added does nothing
by GHC 10 Jun '18

10 Jun '18

#11798: Recompiling with -fhpc flag added does nothing -------------------------------------+------------------------------------- Reporter: drathier | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When you recompile without modifiying any source code, nothing happens, as expected. The file is already compiled, after all. If you then add the -fhpc flag, it still doesn't recompile, even though it now should generate .tix files. These files are now unexpectedly missing, until the source files are modified or the .o and .hi files are deleted, and the code is recompiled again with the -fhpc flag. reproduce: 1. compile program 2. compile program with -fhpc note: missing .tix file 3. delete .hi and .o files 4. compile program with -fhpc 5. success; .tix file is generated -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7