[GHC] #15732: getArgsWithResponseFiles does not filter out RTS options
GHC
ghc-devs at haskell.org
Wed Oct 10 15:35:19 UTC 2018
#15732: getArgsWithResponseFiles does not filter out RTS options
-------------------------------------+-------------------------------------
Reporter: ckoparkar | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.8.1
Component: libraries/base | Version: 8.6.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Incorrect result | Unknown/Multiple
at runtime | Test Case:
Blocked By: | Blocking:
Related Tickets: #13896 | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by ckoparkar):
There's a bigger problem here wrt setting RTS flags via a file.
In the current implementation, {{{getArgsWithResponseFiles}}} is
responsible for for reading any command-line arguments passed via a file.
It iterates over the list returned by {{{getArgs}}}, and issues
{{{readFile}}}'s for appropriate elements (the ones that start with '@').
This means that the RTS never sees any of the flags contained in these
files.
This is fine for regular command-line arguments -- those which are used by
a program, not GHC. But if a file contains any RTS flags ({{{+RTS ...
-RTS}}}) they're completely ignored since {{{getArgsWithResponseFiles}}}
doesn't know what to do with them.
But these flags are indeed special, and we want the RTS to know about
them.
I can think of two ways to fix this:
(1) Properly support response files
Like all the other arguments, the RTS would also process response files
(read, check errors etc.). It can then do the right thing for the flags
contained in these files. We'd also like the main GHC executable to
support response files (see #15072).
(2) Ignore the {{{+RTS ... -RTS}}} flags contained in a response file
Such flags won't have any effect on the RTS.
{{{getArgsWithResponseFiles}}} would just filter these out from it's
return value.
Option (2) is very easy to implement but I don't feel like it's the right
thing to do. I can imagine this causing confusion and further problems. On
the other hand, (1) is a big change which might affect things included in
the Haskell Report.
If we decide to go with option (1), I'd be happy to give it a shot.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15732#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list