Update Windows-specific docs for the clang rewriting tool.

docs/clang_tool_refactoring.md

 # Clang Tool Refactoring
 
 [TOC]
 
 ## Introduction
 
 Clang tools can help with global refactorings of Chromium code. Clang tools can
 take advantage of clang's AST to perform refactorings that would be impossible
 with a traditional find-and-replace regexp:
 
 *   Constructing `scoped_ptr<T>` from `NULL`: <https://crbug.com/173286>
 *   Implicit conversions of `scoped_refptr<T>` to `T*`: <https://crbug.com/110610>
 *   Rename everything in Blink to follow Chromium style: <https://crbug.com/563793>
 
 ## Caveats
 
 An invocation of the clang tool runs on one build config. Code that only
 compiles on one platform or code that is guarded by a set of compile-time flags
 can be problematic. Performing a global refactoring typically requires running
 the tool once in each build config with code that needs to be updated.
 
 Other minor issues:
 
 *   Requires a git checkout.
-*   Requires [some hacks to run on Windows](https://codereview.chromium.org/718873004).
 
 ## Prerequisites
 
 A Chromium checkout created with `fetch` should have everything needed.
 
 For convenience, add `third_party/llvm-build/Release+Asserts/bin` to `$PATH`.
 
 ## Writing the tool
 
 LLVM uses C++11 and CMake. Source code for Chromium clang tools lives in
@@ skipping 74 matching lines @@
 Generally, `--tools` should always include `blink_gc_plugin` and `plugins`: otherwise, Chromium won't build.
 
 It is important to use --bootstrap as there appear to be [bugs](https://crbug.com/580745)
 in the clang library this script produces if you build it with gcc, which is the default.
 
 ## Running
 First, build all Chromium targets to avoid failures due to missing dependencies
 that are generated as part of the build:
 
 ```shell
-ninja -C out/Debug
+ninja -C out/Debug  # For non-Windows
+ninja -d keeprsp -C out/Debug  # For Windows
 ```
 
 Then run the actual tool:
 
 ```shell
 tools/clang/scripts/run_tool.py <toolname> \
   --generate-compdb
   out/Debug <path 1> <path 2> ...
 ```
 
 `--generate-compdb` can be omitted if the compile DB was already generated and
-the list of build flags and source files has not changed since generation.
+the list of build flags and source files has not changed since generation. NOTE:
+On windows to avoid this flag, you must also run the

[dcheng, 2016/12/22 21:31:46]

Nit:
NOTE: On Windows, use generate_win_compdb.py to generate the compile DB instead
of using the --generate-compdb flag.

+`tools/clang/scripts/generate_win_compdb.py` script after generating the compdb.
 
 `<path 1>`, `<path 2>`, etc are optional arguments to filter the files to run
 the tool across. This is helpful when sharding global refactorings into smaller
 chunks. For example, the following command will run the `empty_string` tool
 across just the files in `//base`:
 
 ```shell
 tools/clang/scripts/run_tool.py empty_string  \
   --generated-compdb \
   out/Debug base
@@ skipping 30 matching lines @@
 
 ```shell
 tools/clang/scripts/test_tool.py <tool name>
 ```
 
 The name of the tool binary and the subdirectory for the tool in
 `//tools/clang` must match. The test runner finds all files that match the
 pattern `//tools/clang/<tool name>/tests/*-original.cc`, runs the tool across
 those files, and compared it to the `*-expected.cc` version. If there is a
 mismatch, the result is saved in `*-actual.cc`.