On 10/7/06, Brian Smith <brianlsmith@gmail.com> wrote:

If hs-source-files contains a path with that contains slashes "some/utils," and Extensions: CPP is used, and you compile a lhs file with GHC 6.5 RC2, on Windows, then GHC will generate a lpp file that contains .e.g. "#line 1 "some\utils/Maybes.lhs", and then CPP complains:

C:/Temp/ghc1596_0/ghc1596_0.lpp:1: warning: universal character names are only valid in C++ and C99
C:/Temp/ghc1596_0/ghc1596_0.lpp:1: incomplete universal character name \u

The problem can be fixed by not using platformPath in parseFilePathQ.

See the comments in GHC's DriverPipeline.hs, lines 1364-1372:

    -- We hackily use Option instead of FileOption here, so that the file
    -- name is not back-slashed on Windows. cpp is capable of
    -- dealing with / in filenames, so it works fine. Furthermore
    -- if we put in backslashes, cpp outputs #line directives
    -- with *double* backslashes.   And that in turn means that
    -- our error messages get double backslashes in them.
    -- In due course we should arrange that the lexer deals
    -- with these \\ escapes properly.

Regards,
Brian

On 10/7/06, Duncan Coutts < duncan.coutts@worc.ox.ac.uk> wrote:
Hi all,

I've put up a tarball for the fourth 1.16 Cabal release candidate:

http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz

I had been hoping that this would be the final RC. One bug I've
uncovered is that building the haddock docs for HUnit when cpphs is
installed fails. This is because the Distribution.PreProcess.Unlit.unlit
code produces incorrect output for Test/HUnit/Lang.lhs.

I could do with some help in fixing this.

One can reproduce it with:

cd libraries/HUnit
cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip
-D__GLASGOW_HASKELL__=605 -D__HADDOCK__
ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' <
Lang.lhs > Lang.hs

compare this with:

ghc -E Lang.lhs -o Lang.hspp

and try:

diff Lang.hspp Lang.hs

Cabal's unlit code is incorrectly dropping whitespace and actual tokens.
See especially the last part of that file.

I think this needs fixing asap since the cpphs code path gets used in
preference to the ghc -E path if cpphs is installed. In this example the
symptoms are not too bad as it seems only to be affecting haddock, but I
fear it may break more seriously in other packages.

Duncan

_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel