[PATCH] Fix dependency file escaping

[Sean Silva]

>From a brief look at depfile_parser.in.cc, it looks like Ninja does not
correctly handle GCC's current behavior, and Paul's patch will actually
make it "work". Clearly includes with `#` characters in them don't happen
in practice.

Ninja's depfile_parser.cc tries to express the escaping rules as "backslash
escapes certain characters", which is not the reality. Make's craziness is
such that you cannot tell in isolation whether the backslashes in a
substring `foo\\` need to be escaped or not without looking at the
characters following that substring.

-- Sean Silva

On Fri, May 8, 2015 at 4:36 PM, Nico Weber <thakis at chromium.org> wrote:

> On Fri, May 8, 2015 at 4:01 PM, Paul Robinson <
> Paul_Robinson at playstation.sony.com> wrote:
>
>> In http://reviews.llvm.org/D9208#169446, @thakis wrote:
>>
>> > Does gcc intend to fix this soon? Isn't being compatible with gcc
>> important
>> >  than the other things?
>>
>>
>> If gcc emitted an incorrect relocation, would you argue that it's
>> important to be compatible with gcc?  Even if you could not point to any
>> linker that handled that buggy relocation in a reasonable way?
>>
>
> 'course not, but that's not the case here. If a program (say, ninja) tries
> to be compatible with gnu make's depfile parsing, it would previously
> convert "\ " to a space from what I understand. Now it's going to get "\\\
> " and think that that's "\ ". So this is breaking backwards compat of clang
> with itself.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150508/e7095df9/attachment.html>