Enable /analyze in gn builds

build/config/win/visual_studio_version.gni

Index: build/config/win/visual_studio_version.gni
diff --git a/build/config/win/visual_studio_version.gni b/build/config/win/visual_studio_version.gni
index 60038af0efbf87109d6e47fd2464bf3de8817ab4..97a45ede32abe319300affa00dffb59ec8662208 100644
--- a/build/config/win/visual_studio_version.gni
+++ b/build/config/win/visual_studio_version.gni
@@ -22,6 +22,12 @@ declare_args() {
   windows_sdk_path = "C:\Program Files (x86)\Windows Kits\10"
 
   is_win_fastlink = false
+
+  # Set this to true to enable static analysis through Visual Studio's
+  # /analyze. This dramatically slows compiles and reports thousands of
+  # warnings, so normally this is done on a build machine and only the new
+  # warnings are examined.
+  is_win_analyze = false

[brettw, 2016/02/03 18:48:00]

Does this need to be usable by anywhere other than in the one BUILD file? If
not, then move this declaration to that build file.

[brucedawson, 2016/02/06 01:07:30]

It's need by ffmpeg's build file.

[brettw, 2016/02/19 22:03:05]

With our discussion in chat, I think you can make ffmpeg always remove this
config, so this build flag can be moved to build/config/win/BUILD.gn and not
shared in a .gni file.

Also, can you call this maybe "use_vs_code_analysis"? The problem is that there
are bot steps called "analyze" which seem possibly confusing with the presence
of this name.

[brucedawson, 2016/02/19 22:45:33]

Ah... now I see the advantage of unconditionally removing this in ffmpeg. Okay,
done.
This is a tradeoff. On the one hand the compiler switch is called /analyze and
that's how it's usually discussed, and the gyp files use win_analyze. On the
other hand, confusion with the other analyze steps is real. I think going with
vs_code_analysis makes sense, in which case the config should also be renamed to
win:vs_code_analysis.

 }
 
 if (visual_studio_path == "") {