For whatever reason, I had the file out/gnwin//gen/base/base/trace_event/etw_manifest/chrome_events_win.h in my file system, in addition to the expected file location out/gnwin//gen/base/trace_event/etw_manifest/chrome_events_win.h.

The first file was last touched many months ago, and was virtually empty. Nothing ever picked it up, so it was no problem.

Then I tried the jumbo build today, and I got:

FAILED: obj/base/base/base_jumbo_3.obj 
../../third_party/llvm-build/Release+Asserts/bin/clang-cl --rsp-quoting=posix /nologo /showIncludes  @obj/base/base/base_jumbo_3.obj.rsp /c gen/base/base_jumbo_3.cc /Foobj/base/base/base_jumbo_3.obj /Fd"obj/base/base_cc.pdb"
In file included from gen/base/base_jumbo_3.cc:56:
gen/base/../../../../base/trace_event/trace_event_etw_export_win.cc(30,10):  error: #include resolved using non-portable Microsoft search rules as: gen/base/base/trace_event/etw_manifest/chrome_events_win.h [-Werror,-Wmicrosoft-include]
#include "base/trace_event/etw_manifest/chrome_events_win.h"  // NOLINT
         ^


followed by many screenfuls of errors, and eventually a compiler crash-on-invalid (https://bugs.llvm.org/show_bug.cgi?id=34981).

This is because in Microsoft compilers, the directories of all files in the include stack are also part of the header search path. For details, see slides 34-37 on https://docs.google.com/presentation/d/1oxNHaVjA9Gn_rTzX6HIpJHP7nXRua_0URXxxJ3oYRq0/edit#slide=id.g71ecd450e_2_15 (look at speaker notes)


Since jumbo-generated files hang out in gen/$name like other generated headers, this has the effect of adding gen/$name as a global -I directory for Microsoft compilers, which can cause stale generated files to be picked up, as it was here.


As a fix, I'd suggest that jumbo files go in gen/jumbo/$name instead. That would prevent this.