On Fri, Sep 23, 2011 at 12:42 PM, Douglas Gregor <[email protected]> wrote: > On Sep 18, 2011, at 7:46 AM, Aaron Ballman wrote: > >> This is a fix for Bug 6870. >> >> On Windows, we really do want CRLFs to remain, otherwise the output >> ends up looking incredibly bad when piped to a file (even though it >> looks fine on the command prompt). For instance: >> >> clang.exe -E some_file.cpp > test.txt >> >> With Unix line endings, that will produce output which appears all in >> a single line in some text editors (such as notepad). Such as: >> >> #line 1 "some_file.cpp" #line 1 "some_file.cpp" #line 1 "<built-in>" >> #line 1 "<built-in>" #line 138 "<built-in>" #line 1 "<command line>" >> #line 1 >> and so on... >> >> But with CRLFs, the output ends up looking fine: >> #line 1 "some_file.cpp" >> #line 1 "some_file.cpp" >> #line 1 "<built-in>" >> #line 1 "<built-in>" >> #line 138 "<built-in>" >> #line 1 "<command line>" >> #line 1 > > > The use of binary mode was intentional, because we didn't want to translate > files with just LF's to CRLF's. The ideal behavior would probably be to emit > CRLF's consistently if the input file used CRLF, and emit LF's consistently > otherwise.
Here's another attempt -- this time I am trying to determine the original file's line endings so I can match them. I do this by looking at the first N bytes of the file to find a CRLF, CR or LF. I'm uncertain of whether it's worth it to move the line ending check code into llvm\Support\FileUtilities.h or not. Thanks for the review! ~Aaron
OptELineEndings.diff
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
