Could you add unit tests for methods in List and NNS? OK if they are in a separate patch.

Please also add appropriate handling to syntax::List::getDelimiterTokenKind, getTerminationKind, and canBeEmpty.

LGTM!

I'd suggest to drop the <> quotes (because the AST dump does not add quotes unless it is printing a multi-word thing, and because <> don't exactly scream "role" helping to read the output).

Node::dumpTokens was never used.

I feel uneasy about adding this code without tests. Could we maybe port the function parameter list to use this infrastructure, and then add tests that exercise getElementsAsNodesAndDelimiters?

Passed test cases but failed in the real world as std::string has a non trivial destructor so creates a CXXBindTemporaryExpr.

What is this diff based on? On the left I see, for example, NamespaceNameSpecifier, which is not in the repository yet.

Generally in Python it is preferred to have more strongly typed inputs than stringifying whatever comes in. If you feel like this is the best choice, I don't mind.

Did your latest update unintentionally drop the test file clang/test/Analysis/ns_error_enum.m?

Could you take a look at test failures and check if they are relevant? linux > Clang.AST::ast-dump-attr.cpp looks extremely close to the area you're working on.

Fix crash on user defined literals

I reverted your commit because it seemed to have broken the build:

However, is this worth an RFC to the list?

Now, in all the test cases we are calling the default implementation. We are not surfacing that WalkUpFrom can not walk up.

I generally avoid testing error message content in tests, but I know there's a variety of opinions on this subject...

In D82226#2115406, @asoffer wrote:

I think the tradeoff here is
Dynamic typing -- faster compile times, type safety checked at run-time (in tests), lower maintenance cost
Templates -- Faster runtime, type safety checked at compile-time, better user expereience

Any chance for a test?

@vvereschaka Sorry about that. It looks like a bug in MSVC. I implemented a workaround in https://reviews.llvm.org/D82636 -- please review if you have time.