text: Opened 8 years ago
  Closed 7 years ago
  #2152 closed bug (fixed)
  bogus inlining of foreign import "foo.h &foo"
  Description
  Foreign imports with include file annotations are not supposed to be inlined, because if they end up crossing a module boundary the include file might not be available when compiling the importing module.
  This works by making the Id representing the foreign call NOINLINE, which is done in DsForeign.dsCImport. Unfortunately with the example below, the Id still gets inlined into another binding, and thereby escapes the module.
  module Curses (screen_size) where import Foreign data WINDOW = WINDOW type WINDOWptr = Ptr WINDOW foreign import ccall unsafe "curses.h & stdscr" stdscrp :: Ptr WINDOWptr screen_size :: IO () screen_size = do stdscr <- peek stdscrp return ()
  Compile with GHC 6.8.2, -O.
  Change History (9)
  comment:1 Changed 8 years ago by simonmar
  comment:2 Changed 8 years ago by igloo
  - Priority changed from normal to low
  This probably isn't worth spending the time on just for 6.8.3.
  comment:3 Changed 8 years ago by simonpj
  Punting for 6.8.3 is probably ok, but it's on my list because NOINLINE should make a definition opaque, but doesn't. That's because exprIsConApp_maybe doesn't take account of it. In principle this might affect other program too. I'll get to it.
  Simon
  comment:4 Changed 8 years ago by simonmar
  - Owner set to simonpj
  comment:5 Changed 8 years ago by igloo
  - Milestone changed from 6.8.3 to 6.10 branch
  - Priority changed from low to normal
  comment:6 Changed 8 years ago by simonmar
  - Architecture changed from Unknown to Unknown/Multiple
  comment:7 Changed 8 years ago by simonmar
  - Operating System changed from Unknown to Unknown/Multiple
  comment:8 Changed 7 years ago by igloo
  - Milestone changed from 6.10 branch to 6.12 branch
  comment:9 Changed 7 years ago by simonmar
  - Milestone changed from 6.12 branch to 6.10.1
  - Resolution set to fixed
  - Status changed from new to closed
  This was fixed in 6.10.1.
  This is not an issue in HEAD, incedentally, which now doesn't need or use external header files when compiling via C.