4th Cabal-1.1.6 release candiate
brianlsmith at gmail.com
Sat Oct 7 14:56:43 EDT 2006
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.
On 10/7/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> Hi all,
> I've put up a tarball for the fourth 1.16 Cabal release candidate:
> 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.
> cabal-devel mailing list
> cabal-devel at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cabal-devel