#14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description:
Today I spent a fair amount of time looking at the STG linter, having encountered a number of times in the past six months where I noticed it broke.
While I thought fixing it would just be a few small tweaks, it seems that with every issue I fix another bug rears its ugly head. So far I have encountered and fixed, * #14116 * #14117 * #14118 The solutions to each of these has seemed rather obvious. However, now I seem to have run into a bit of a more fundamental issue:
Consider this excerpt extracted from `Foreign.Storable`, {{{#!hs {-# LANGUAGE BangPatterns #-}
module Hi where
import GHC.Word import GHC.Ptr import GHC.Base import GHC.Num import Data.Bits import GHC.Fingerprint.Type
peekFingerprint :: Ptr Fingerprint -> IO Fingerprint peekFingerprint p0 = do let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 peekW64 _ 0 !i = return i peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8)
high <- peekW64 (castPtr p0) 8 0 low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 return (Fingerprint high low) }}}
In particular notice the `castPtr` application. This triggers the STG linter with, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, eta_s2zC :: State# RealWorld] In a function application, function type doesn't match arg types: Function type: Ptr Word8 -> Int# -> Word# -> State# RealWorld -> (# State# RealWorld, Word64 #) Arg types: Ptr Fingerprint Int# Word# State# RealWorld Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC }}}
This is because by the time we are in Core Prep the `castPtr` is turned into a cast, which we discard in STG. Consequently, it seems that the comment attached to `stgEqType`, {{{#!hs stgEqType :: Type -> Type -> Bool -- Compare types, but crudely because we have discarded -- both casts and type applications, so types might look -- different but be the same. So reply "True" if in doubt. -- "False" means that the types are definitely different. -- -- Fundamentally this is a losing battle because of unsafeCoerce }}} is quite an understatement. Rather, there are exceedingly few cases where we can catch any type errors in STG. I think the only case which we can reliably catch is that of two types with explicitly different primreps. It's not clear what we can/should do about this.
New description: Today I spent a fair amount of time looking at the STG linter, having encountered a number of times in the past six months where I noticed it broke. While I thought fixing it would just be a few small tweaks, it seems that with every issue I fix another bug rears its ugly head. So far I have encountered and fixed, * #14116 * #14117 * #14118 The solutions to each of these has seemed rather obvious. However, now I seem to have run into a bit of a more fundamental issue: Consider this excerpt extracted from `Foreign.Storable`, {{{#!hs {-# LANGUAGE BangPatterns #-} module Hi where import GHC.Word import GHC.Ptr import GHC.Base import GHC.Num import Data.Bits import GHC.Fingerprint.Type peekFingerprint :: Ptr Fingerprint -> IO Fingerprint peekFingerprint p0 = do let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 peekW64 _ 0 !i = return i peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) high <- peekW64 (castPtr p0) 8 0 low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 return (Fingerprint high low) }}} In particular notice the `castPtr` application. This triggers the STG linter with, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, eta_s2zC :: State# RealWorld] In a function application, function type doesn't match arg types: Function type: Ptr Word8 -> Int# -> Word# -> State# RealWorld -> (# State# RealWorld, Word64 #) Arg types: Ptr Fingerprint Int# Word# State# RealWorld Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC }}} This is because by the time we are in Core Prep the `castPtr` is turned into a cast, which we discard in STG. Consequently, it seems that the comment attached to `stgEqType`, {{{#!hs stgEqType :: Type -> Type -> Bool -- Compare types, but crudely because we have discarded -- both casts and type applications, so types might look -- different but be the same. So reply "True" if in doubt. -- "False" means that the types are definitely different. -- -- Fundamentally this is a losing battle because of unsafeCoerce }}} is quite an understatement. Rather, there are exceedingly few cases where we can catch type errors in STG. I think the only case which we can reliably catch is that of two types with explicitly different primreps. It's not clear what we can/should do about this. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14120#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler