CPP strips out C-style comments

[nominolo]

The following code fails to compiler with `y` not in scope:

{-# LANGUAGE CPP #-}
module Foo (x) where

x = ([y], z)

-- Oh, noes! Here comes a C-style comment: /usr/local/*
y = 42

-- And now let's close it */Setup.hs accidentally
z = 23

Apparently, the part between the /* and the */ got stripped out by the preprocessor. If we use a gcc's CPP mode, we should at least pass it some options to prevent this from happening.

[malcolm.wallace@…]

Stripping C comments is part of the normal tokenisation behaviour of CPP. There are no options to gcc to turn it off. See for instance  http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC2

If you want to avoid C-tokenisation but still use CPP with Haskell, try cpphs instead.

[igloo]

As I understand it, there's no way we can stop cpp doing this, so I'm closing this bug.

[nominolo]

At least my version of cpp (GNU cpp on Mac OS X 10.5) claims to have this option:

       -C  Do not discard comments.  All comments are passed through to the
           output file, except for comments in processed directives, which are
           deleted along with the directive.

           You should be prepared for side effects when using -C; it causes the
           preprocessor to treat comments as tokens in their own right.  For
           example, comments appearing at the start of what would be a directive
           line have the effect of turning that line into an ordinary source
           line, since the first token on the line is no longer a #.

[igloo]

Thanks Malcolm, quite right. I've attached a patch to fix this.

However, the build breaks when compiling dph, as dph uses the Cabal auto-generated header files in Haskell files, which end up containing something like

/* DO NOT EDIT: This file is automatically generated by Cabal */
/* package array-0.3.0.0 */
/* package base-4.3.0.0 */
/* package dph-base-0.4.0 */
module Data.Array.Parallel.Lifted.Instances

They could be switched to use Haskell comments, but I don't know if being able to include them in C files is also important; Duncan?

The fix to this will be easy, once we work out what the desired behaviour is...

[duncan]

Replying to igloo:

They could be switched to use Haskell comments, but I don't know if being able to include them in C files is also important; Duncan?

The cabal_macros.h file can be included by C code and it'd be useful to do so. I guess if we ever switch to cpphs we would have the same problem.

Note that the cabal_macros.h is not the only problem. Other packages #include header files that contain no C code but only macros and comments.

Hmm.

[malcolm.wallace@…]

Perhaps one solution might be to have two different LANGUAGE pragmas for CPP, to allow the file to choose its desired behaviour for the preprocessor, e.g. CPP and CPPKeepCComments. (Or with the alternative default choice, CPP and CPPStripCComments.)

[igloo]

I think the default will have to stay as it is (i.e. stripping C comments).

You can use

{-# LANGUAGE CPP #-}
{-# OPTIONS_GHC -optP -C #-}

if you know you want comments to be kept.