patch applied (ghc): -fno-code shouldn't be a mode.

[Simon Marlow]

Lemmih wrote:
> On 3/22/06, Simon Marlow <simonmarhaskell at gmail.com> wrote:
> 
>>David Himmelstrup wrote:
>>
>>>Sat Mar 18 09:17:28 PST 2006  Lemmih <lemmih at gmail.com>
>>>  * -fno-code shouldn't be a mode.
>>>
>>>  I've removed -fno-code from Main to make it work
>>>  equally well with --make and -c.
>>>  I've also allowed it not to write hi files unless
>>>  -fwrite-iface is given.
>>>
>>>
>>>    M ./ghc/compiler/main/CodeOutput.lhs +1
>>>    M ./ghc/compiler/main/DriverPipeline.hs -25 +4
>>>    M ./ghc/compiler/main/DynFlags.hs -4 +10
>>>    M ./ghc/compiler/main/HscMain.lhs -2 +4
>>>    M ./ghc/compiler/main/Main.hs -6 +7
>>
>>I've just noticed a couple of problems with this.  I'm off home now so I
>>haven't got time to investigate any further, but:
>>
>>   - -keep-s-files shouldn't turn on -fasm, since you can get .s files
>>     from via-C compilation too.  This is easily fixable.
>>
>>   - the hscMaybeAdjustLang thing was there to handle stuff like this:
>>
>>$ ghc -C -fasm hello.hs
>>ghc-6.5.20060322: panic! (the 'impossible' happened)
>>   (GHC version 6.5.20060322 for x86_64-unknown-linux):
>>         pipeLoop: at phase As but I wanted to stop at phase HCc
>>
>>there may be other effects, I'm not sure.
> 
> 
> Hm, right. I'll revert the changes and return in a couple of days when
> I've figured out how to simplify the pipeline enough to wrap my head
> around it.

I'll add a test for that case, too.  BTW, the driver tests are very 
useful when playing with the pipeline code: just go into 
testsuite/tests/ghc-regress/driver and say 'make'.

> In particular, I've been thinking about refactoring out the
> preprocessing to allow a full compilation plan to be generated before
> it's executed, and, consequently, hoisting 'getOutputFilename' out of
> the inner loop.

In fact, this is how it used to be done.   One problem with that is that 
you can't always generate the pipeline beforehand, because the {-# 
OPTIONS_GHC #-} pragma might include -fvia-C, for example.

I'm aware that this part of the compiler resists comprehension to some 
extent :-)  By all means try to refactor it.  I would point out, though, 
that the current design is the result of several iterations, and IMO the 
real problem is that the semantics we have to implement is just a bit weird.

Cheers,
	Simon