Recognise language pragmas generated by custom pre-processors (run with -F)

[dorchard]

A custom pre-processor might desugar terms into terms of a particular language extension, requiring a new language pragma. Currently, any language pragmas generated by a pre-processor will be ignored once the pre-processed file is picked up by GHC again.

As a contrived example, consider foo.hs:

{-# OPTIONS -F -pgmF ./preprocess.sh #-}

data Foo a where MkFoo :: Foo a

where preprocess.sh:

#!/bin/sh
( echo "{-# LANGUAGE GADTs #-}"; cat $2; ) > $3

Currently we get this behaviour:

bash-3.2$ ghc foo.hs

/tmp/ghc7191_0/ghc7191_0.hspp:4:0:
    Illegal generalised algebraic data declaration for `Foo'
      (Use -XGADTs to allow GADTs)
    In the data type declaration for `Foo'

bash-3.2$ ghc foo.hs -E
bash-3.2$ cat foo.hspp
{-# LANGUAGE GADTs #-}
{-# OPTIONS -F -pgmF ./preprocess.sh #-}

data Foo a where MkFoo :: Foo abash-3.2$ 

It would be nice if GHC noticed the new pragmas, particularly language pragmas, although perhaps not all pragmas should be picked up (maybe not new OPTION pragmas).

[duncan]

#3457 and #2464 are bugs with the same fix.

They are all instances of the same problem in the way ghc handles information gleaned from source files prior to pre-processing (with cpp or a custom pre-processor).

See #3457 for a description.

[simonmar]

Fixed:

Fri Jan 29 03:40:50 PST 2010  Simon Marlow <marlowsd@gmail.com>
  * Re-read pragmas after preprocessing (#2464, #3674, #3457)