[PATCH] Fix dependency file escaping

[Robinson, Paul]

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 "\ ".

You're mixing things up.  #include "\ " would be converted by gcc to "\\ " (because it escapes the space but not the backslash) which would be de-escaped by GNU Make as "\" followed by a space delimiter.
Now Clang will give it "\\\ " which will be handled as "\ " which is correct.
(Remember that the string you hand to #include is NOT a normal C string; it has no escaping in it.)
--paulr

From: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] On Behalf Of Nico Weber
Sent: Friday, May 08, 2015 4:36 PM
To: reviews+D9208+public+0ac91376ffbd3e34 at reviews.llvm.org
Cc: cfe-commits at cs.uiuc.edu
Subject: Re: [PATCH] Fix dependency file escaping

On Fri, May 8, 2015 at 4:01 PM, Paul Robinson <Paul_Robinson at playstation.sony.com<mailto: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/20150509/fafb0c20/attachment.html>