[cfe-commits] [PATCH] Using proper file mode for -E

[Aaron Ballman]

On Fri, Sep 23, 2011 at 4:54 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Sep 23, 2011, at 2:39 PM, Aaron Ballman wrote:
>
>> On Fri, Sep 23, 2011 at 12:42 PM, Douglas Gregor <dgregor at apple.com> 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'd like to avoid loading the file just for this purpose. Is it possible to use the SourceManager to get at the main file's buffer and check there, so that we just re-use the already-loaded main source file?

I was unaware that was even an option -- it certainly makes me feel
more comfortable.  Here's the latest patch.  Is it valid for me to be
assuming the file we're after is the same one returned by
getMainFileID?

Thank you for the attention, I'm still learning my way around the code base.

~Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OptELineEndings.diff
Type: application/octet-stream
Size: 2576 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110923/44c621fa/attachment.obj>