So far I have narrowed down the repro to:

template<class... Ts> struct foo : _Arg_types<Ts...> { typedef int type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };
template<class... Ts> struct foo<void(Ts...)> : _Arg_types<Ts...> { typedef type1 type_alias; };

template<class T>
struct add_const {
  typedef const T type;
};

namespace some_namespace {
  using ::other_namespace:: add_const;
}

template<class T>
using add_const_t = typename add_const<T>::type;

template<class T> inline
constexpr add_const_t<T>& as_const(T& v) { return v; }



Notes:
- I have trouble narrowing down further (i.e. removing any of the duplicated 9 lines will make the repro go away).
- The AST-related assert is hit despite the narrowed down repro resulting in compilation errors.

Maybe it's somehow due to delayed template parsing (cf eg https://chromium.googlesource.com/chromium/src/+/28c1b1099fb09782841d891ca43e83e71cd8dfc6)

RE: #c2

Thanks for the pointer - this does sounds quite promising.

Is there a way to quickly test this?  I tried adding -fno-delayed-template-parsing to compile_commands.json used by rewrite_to_chrome_style.exe, but (I guess expectedly, per  https://crbug.com/486571#c10 ) got back a warning: unknown argument ignored in clang-cl: '-fno-delayed-template-parsing'.

I guess another way to test this would be to try a similar fix for rewrite_to_chrome_style.exe, but I have a little bit of trouble figuring out how to hook it up:

1. There is clang::ast_matchers::internal::<anonymous>::MatchASTConsumer::HandleTranslationUnit that seems like a perfect place for duplicating the fix done by https://codereview.chromium.org/1140443005/patch/20001/30001 in tools/clang/blink_gc_plugin/BlinkGCPlugin.cpp.  The problem is that I don't see a way to grab a clang::CompilerInstance pointer from within MatchASTConsumer::HandleTranslationUnit (where I only have pointers to clang::ast_matchers::ASTMatchFinder and to clang::ASTContext - I looked at these 2 classes but they don't seem to offer an accessor for clang::CompilerInstance)

2. I guess I could try to modify RewriteToChromeStyle.cpp instead, which sees a CompilerInstance in SourceFileCallbacks, but I am not sure how to properly chain/glue together 2A) my hypothetical, new ASTConsumer and 2B) the old MatchASTConsumer.  Maybe I shouldn't worry about this too much, because MatchASTConsumer only needs forwarding of a single override - HandleTranslationUnit.  Hmmm... maybe this is what I should try next :-)

+klimek@ who might be interested in this bug around AST matchers

On second thought, I am not sure if the fix from  https://crbug.com/486571  would help here, because
1) here we are getting an assert when looking at AST node from a system header
2) the fix for the other bug explicitly tries to avoid processing of system headers (here: https://chromium.googlesource.com/chromium/src/+/06f6cd0653d33dc0e087cf3aede5df399ffc9db0/tools/clang/blink_gc_plugin/BlinkGCPluginConsumer.cpp#143)

klimek@, how much would you object to the idea of replacing the assert with a fallback:
   if (Parents.empty()) return false;
I guess having a unit/regression test would probably go a long way toward making this "fix" more acceptable for upstream clang.  FWIW, I am using this "fix" as a workaround to unblock myself and attempt to discover any other Windows-specific problems with running rewrite_to_chrome_style clang tool.

The assert has found lots of useful bugs that we fixed. I think it's a useful assert.

My understanding from thakis@ is that these represent real bugs in clang's AST representation.

For us to proceed, it's fine to patch out the check locally, but it's probably not something we want upstream.

WontFix from us I think, unless someone wants to pick it up.