Admin message

Due to a large amount of spam we do not allow new users to create repositories, they are "external" users. If you are a new user and want to create a repository, for example for forking GHC, open a new issue on ghc/ghc using the "get-verified" issue template

Weird error messages involving type families in do notation
## Summary When using a type family with `do` notation, the error message for the result type of the `do` block appears in the wrong location. The behavior is different when not using the type family. ## Steps to reproduce consider the following program: ```haskell {-# LANGUAGE TypeFamilies #-} module Weird where x = foo $ \a -> do y pure () y :: IO () y = undefined type family K a where K a = Bool foo :: (a -> IO (K b)) -> t foo = undefined ``` ``` Weird.hs:5:3: error: [GHC-83865] • Couldn't match type ‘()’ with ‘Bool’ Expected: IO (K b0) Actual: IO () • In a stmt of a 'do' block: y In the expression: do y pure () In the second argument of ‘($)’, namely ‘\ a -> do y pure ()’ | 5 | y | ^ ``` The type of `y` is clearly correct, the type that is incorrect is the one of `pure ()`. Thus the error should be at line 6. This is especially confusing when the `do` block is longer ## Expected behavior The type error should show up on the stmt that actually has the wrong type (`pure ()`) The behaviour should, in fact, be identical to the one of this program: ```haskell {-# LANGUAGE TypeFamilies #-} module Weird where x = foo $ \a -> do y pure () y :: IO () y = undefined -- type family K a where -- K a = Bool foo :: (a -> IO Bool) -> t foo = undefined ``` Which intuitively reports: ``` Weird.hs:6:8: error: [GHC-83865] • Couldn't match expected type ‘Bool’ with actual type ‘()’ • In the first argument of ‘pure’, namely ‘()’ In a stmt of a 'do' block: pure () In the expression: do y pure () | 6 | pure () | ^^ ``` ## Environment * GHC version used: 9.10.1, 9.12.1 Optional: * Operating System: NixOS 25.05 * System Architecture: x86_64-linux As a workaround, you could use `K a ~ b` but that doesn't improve ergonomics considerably - the error message shows up on `foo` then, which imo is still the "wrong" place even though I now understand why it is like that.
issue