Have CanonicalizePath handle \ on Windows

Have CanonicalizePath handle \ on Windows. It's slightly slower to do so, so compensate for that by improving ReadFile to not use text mode (which is a bit slower), and then fixing the lexer to accept \r (it was previously relying on reading files in text mode to remove '\r's).

Timings:

before patch:
qpc: 1229494us
qpc: 1232420us
qpc: 1232493us
qpc: 1235035us
qpc: 1239521us
qpc: 1247100us
avg = 1234867us

with canon of \, fixing parser to accept \r and speedier ReadFile
qpc: 1196304us
qpc: 1200643us
qpc: 1187478us
qpc: 1190062us
qpc: 1182991us
qpc: 1203037us
avg = 1190128us

On Wed Oct 29 2014 at 9:15:45 PM Nico Weber <notifications@github.com>
wrote:

> In src/util.cc:
>
> > @@ -115,29 +115,39 @@ bool CanonicalizePath(char* path, size_t* len, string* err) {
> >    const char* src = start;
> >    const char* end = start + *len;
> >
>
> The changes to this function are pretty ugly. Can you just convert all \\
> to / at the top? (maybe after the network path handling, dunno if they're
> interchangeable there) Or is that much slower?
>

That was a little slower when I tested, but still less slower than the
amount the file reading change saves. So, I'll do that.

(I sort of forgot why I was doing this in the first place. The current code
only fixes \ being treated as a filename character rather than a separator,
but doesn't normalize to /. But that won't help downstream if the generator
emits all / and expects them to match up with another tool emitting as \.)


> —
> Reply to this email directly or view it on GitHub
> <https://github.com/martine/ninja/pull/839/files#r19587234>.
>