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

GHC ghc-devs at haskell.org
Thu Oct 18 07:11:21 UTC 2018


#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 osa1):

 OK so if I understand this correctly here's how this happens:

 - hsc2hs built using bootstrap compiler, which in my case is 8.4.4, which
 doesn't have `getArgsWithResponseFiles` function.
 - So in
 [https://github.com/haskell/hsc2hs/commit/0535fe65467d1a07b838c17c62438086c12e98a9
 this commit] the code with `getArgs` is used.
 - However, Cabal doesn't consider this possibility that a new enough GHC
 is built using a GHC without `getArgsWithResponseFiles`, and just based on
 hsc2hs version thinks that it should support `getArgsWithResponseFiles`,
 and passes arguments usign response file conventions.

 The question is: is this a GHC bug or a Cabal bug?

 - If we want newer GHCs (HEAD, 8.8) to always support response files this
 is a GHC bug.
 - Otherwise this is a Cabal bug.

 > We certainly can't move hsc2hs out of 'Phase 0' as some artifacts in
 'Phase 1' depend on it

 What do you mean by "Phase"? I think we can build hsc2hs using stage 1
 compiler and libs and that'd fix the problem, no? Any .hsc files for stage
 1 can be compiled using bootstrap hsc2hs.

 Here's the hack I used to fix this on Cabal side:

 {{{
 diff --git a/Cabal/Distribution/Simple/PreProcess.hs
 b/Cabal/Distribution/Simple/PreProcess.hs
 index daf419ef2..da231f9a0 100644
 --- a/Cabal/Distribution/Simple/PreProcess.hs
 +++ b/Cabal/Distribution/Simple/PreProcess.hs
 @@ -396,7 +396,7 @@ ppHsc2hs bi lbi clbi =
        (hsc2hsProg, hsc2hsVersion, _) <- requireProgramVersion verbosity
                                            hsc2hsProgram anyVersion
 (withPrograms lbi)
        -- See Trac #13896 and
 https://github.com/haskell/cabal/issues/3122.
 -      let hsc2hsSupportsResponseFiles = hsc2hsVersion >= mkVersion
 [0,68,4]
 +      let hsc2hsSupportsResponseFiles = False
            pureArgs = genPureArgs gccProg inFile outFile
        if hsc2hsSupportsResponseFiles
        then withResponseFile
 }}}

 I'd suggest bumping priority, but I guess we should first decide whether
 to fix this on GHC side or Cabal side.

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


More information about the ghc-tickets mailing list