I see the following text in compile_commands.json on Windows:

... -D\"I18N_ADDRESS_VALIDATION_DATA_URL=/\"https://chromium-i18n.appspot.com/ssl-aggregate-address//\"\" ...

On linux this commandline parameter looks as follows:

... -DI18N_ADDRESS_VALIDATION_DATA_URL=\\\"https://chromium-i18n.appspot.com/ssl-aggregate-address/\\\" ...

This is because gen_compdb.py tries to change Windows-style path separators to POSIX-style path separators. Sigh.

(And the reason we do this is because various things didn't agree on how backslashes should be escaped in compile_commands.json)

Also, does this actually affect any files that would matter to us? If not, I think we can just ignore this issue.

RE: #c5

It affects quite a few files, so there is worry that other, more important failures might drown in the noise.

OTOH, I don't know if this affects sources that we need to touch during the rename (in Blink and in immediate users of Blink in content and components).  FWIW, I've tried running the renaming tool just on third_party/WebKit/Source/wtf and it worked just fine (I was even able to build  third_party/WebKit/Source/wtf:wtf_unittests target [without needing any manual fixes, just like on Linux]).

Are you running the tool in git bash or in cmd.exe? I suggest the former. Everything worked for me there.

I think the backslash escaping will affect you no matter where. Perhaps clang tooling handles it more sanely now: what happens if we just remove the s/\\/\//?

RE: #c9

It seems promising.  I've commented out the following 3 lines:
  #e['directory'] = e['directory'].replace('\\', '/')
  #e['command'] = e['command'].replace('\\', '/')
  #e['file'] = e['file'].replace('\\', '/')
in generate_win_compdb.py and after processing 25% of files there are only 2 errors (which reproed before this change as well;  I'll open a separate bug in a minute).

I don't know which other tools might depend on compile database.  Should I try landing removal of the escaping below and watching if anything breaks?

We are the only thing that uses gen_compdb.py =)

I guess something must have changed in this area; it used to be that it was impossible for clang tooling to correctly parse the \ embedded in those fields, but if it Just Works, we should just remove those lines.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/81048ff960a98b09ce0d37a735c7fe7d4224aceb

commit 81048ff960a98b09ce0d37a735c7fe7d4224aceb
Author: lukasza <lukasza@chromium.org>
Date: Fri Feb 03 22:45:58 2017

Stop special handling of backslashes in compilation command lines.

1. The special handling was incorrectly mangling URIs ( https://crbug.com/688199#c1 )
2. The special handling apparently is not needed anymore - clang tool
   runs fine without it ( https://crbug.com/688199#c10 )

BUG= 688199 

Review-Url: https://codereview.chromium.org/2673683006
Cr-Commit-Position: refs/heads/master@{#448097}

[modify] https://crrev.com/81048ff960a98b09ce0d37a735c7fe7d4224aceb/tools/clang/scripts/generate_win_compdb.py