[GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable

[GHC]

#15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:
      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:                    |
-------------------------------------+-------------------------------------

Comment (by ckoparkar):

 Here's another way to reproduce the build failure. If we create a
 'Foo.hsc' file,
 and use {{{hsc2hs}}} built by HEAD to process it via a response file, it
 fails with the same error.

 {{{#!haskell
 -- Foo.hsc
 main :: IO ()
 main = print $ #size int
 }}}

 {{{#!sh
 $ cat cmd_opts
 Foo.hsc
 }}}

 {{{#!sh
 $ ~/ghc/inplace/bin/hsc2hs @cmd_opts
 hsc2hs: @cmd_opts: openBinaryFile: does not exist (No such file or
 directory)
 }}}

 And this would always fail if HEAD is built with GHC < 8.6.

 I think that it's because in the GHC build system,
 {{{hsc2hs}}} is built during Phase 0, by the bootstrapping compiler.
 So if HEAD is bootstrapped with GHC < 8.6, it uses a version of {{{base}}}
 which
 does not support response files, and triggers a CPP codepath which does
 not
 know how to parse {{{@file}}} command-line arguments. So {{{hsc2hs}}}
 tries to read a '@file',
 which does not exist.

 I am unsure what right solution for this is.
 We certainly can't move {{{hsc2hs}}} out of 'Phase 0' as some artifacts in
 'Phase 1'
 depend on it. Maybe the final {{{hsc2hs}}} executable that's generated
 under
 'ghc/inplace' could be regenerated in a later phase.
 What do other people think about this ?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15758#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler