Clang CPP adds extra newline character

Running the following command (taken from the settings file)

cat ImportsSemi.hs | gcc -E -undef -traditional -Wunicode -Wno-invalid-pp-token -Wno-unicode - > out.hs

on any file results in a file which has an extra newline character appended to the end. This result is different from when gcc is used as the preprocessor, in this case no extra newline is appended.

I appreciate that this isn't important to most users but it is important for ghc-exactprint. With the extra newline character the EOF marker is moved one line further down. When we come to output the AST, we also get an extra newline at the bottom of the file which breaks roundtripping.

> gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

Trac metadata

Trac field	Value
Version	7.8.4
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import cpp labels

mentioned in issue #10147 (closed)

How is this a GHC issue? That is, what change to GHC would you like to see here?

It sounds like you would like clang's CPP to be "fixed", but I don't think it is really buggy, since the semantics of CPP are defined in terms of tokenized C programs, and adding a trailing newline does not change that tokenization. So, I would not be too hopeful about submitting a bug report, but you could try.

I also don't really understand what you are trying to do at all here, isn't the CPP phase quite irreversible regardless of this trailing newline issue? Could you go into more detail about your use case?

I think you're right that it's not a GHC issue and there's nothing that would be sensible to change in GHC. It's possible to reverse some simple CPP changes but you're right that in general it is a difficult problem.

closed

Replying to [ticket:10146#comment:97188 mpickering]:

I think you're right that it's not a GHC issue and there's nothing that would be sensible to change in GHC.

Unless you change your mind, lets close this then.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

added Pnormal label