Set using_sanitizer if use_cfi_diag is true.

build/config/sanitizers/BUILD.gn

Index: build/config/sanitizers/BUILD.gn
diff --git a/build/config/sanitizers/BUILD.gn b/build/config/sanitizers/BUILD.gn
index 637fc881174f37fbcf016d8e314c1f3315ba55fb..459b73e3bba849b2e1e1553fef8437f887c1e329 100644
--- a/build/config/sanitizers/BUILD.gn
+++ b/build/config/sanitizers/BUILD.gn
@@ -272,8 +272,8 @@ config("common_sanitizer_flags") {
   }
 
   # Common options for AddressSanitizer, LeakSanitizer, ThreadSanitizer,
-  # MemorySanitizer and non-official CFI builds.
-  if (using_sanitizer || (is_cfi && !is_official_build)) {
+  # MemorySanitizer and CFI with diagnostics.
+  if (using_sanitizer) {
     if (is_posix) {
       cflags += [ "-fno-omit-frame-pointer" ]

[Nico, 2017/06/19 19:29:41]

This still doesn't happen in prod builds, right? Can you maybe add a
assert(!is_official_build) here?

[pcc1, 2017/06/19 22:18:52]

That would essentially forbid sanitizers in official builds, right? Is that a
good idea?

[Nico, 2017/06/19 23:50:28]

I think so?  Not sure, but with this change it seems easier to accidentally ship
a sanitizer build to prod, and generally we don't want to do this, right?

When we ship asan binaries to canary, I'd expect that that would just set
is_chrome_branded but not is_official_build, else we grow yet another build
config to maintain.

[pcc1, 2017/06/19 23:59:08]

Seems reasonable enough. I was imagining that people might want to use a
sanitizer to debug something in an official build, but the tradeoff seems to be
in favour of hacking the build config locally in those cases.

     } else {