blockio: expose serialHasBlockIO from an internal module

We use `serialHasBlockIO` in the `sim` sub-library and so we have to expose it
somewhere, but we'd actually prefer it if it was not part of the public API.
Exposing it only from an internal module makes it clear that it should ideally
not be used by users.

Author: jorisdral

blockio/blockio.cabal

@@ -69,9 +69,12 @@ library
   exposed-modules:
     System.FS.BlockIO.API
     System.FS.BlockIO.IO
+    System.FS.BlockIO.Serial.Internal
+
+  other-modules:
+    System.FS.BlockIO.IO.Internal
     System.FS.BlockIO.Serial
 
-  other-modules:   System.FS.BlockIO.IO.Internal
   build-depends:
     , base        >=4.16  && <4.22
     , deepseq     ^>=1.4  || ^>=1.5

blockio/src-sim/System/FS/BlockIO/Sim.hs

@@ -18,7 +18,7 @@ import qualified System.FS.API.Lazy as API
 import qualified System.FS.API.Strict as API
 import           System.FS.BlockIO.API (HasBlockIO (..), LockFileHandle (..),
                      LockMode (..))
-import           System.FS.BlockIO.Serial
+import           System.FS.BlockIO.Serial.Internal
 import           System.FS.CallStack (prettyCallStack)
 import           System.FS.Sim.Error
 import           System.FS.Sim.MockFS hiding (hClose, hOpen)

blockio/src/System/FS/BlockIO/Serial/Internal.hs

@@ -0,0 +1,12 @@
+-- | This is an internal module that has to be exposed for technical reasons. Do
+-- not use it.
+module System.FS.BlockIO.Serial.Internal (
+    -- We have to re-export from somewhere so that the @blockio:sim@ sub-library
+    -- can use it. Unfortunately, this makes the function part of the public API
+    -- even though we'd prefer to keep it truly hidden. There are ways around
+    -- this, for example using a new private sub-library that contains the
+    -- "System.FS.BlockIO.Serial" module, but it's a lot of boilerplate.
+    serialHasBlockIO
+  ) where
+
+import           System.FS.BlockIO.Serial (serialHasBlockIO)