Ah, it didn't occur to me that grep was a sign of old test harness. Here's a FileCheckified version. I took the opportunity to combine the two testcases, as there didn't seem a need to keep them separate any more.

Thanks, I didn;'t know about ClassifyName, and obviously never hit a need to adjust it. Thanks for fixing.

In D135799#3855483, @urnathan wrote:

In D135799#3855419, @ldionne wrote:

I think it would actually be better to define #define _LIBCPP_ENABLE_ASSERTIONS 0 at the top of the file. That way, we (1) retain the ability to use std algorithms, and we don't risk someone else breaking this in the future. WDYT?

I thought you disliked that solution -- have you changed your mind? (the define would work for me too)

It occurs to me that for systems that lack dynamic initialization (like PTX), it is trivial to implement the 'don't call NOP module inits', because we know that there can be no non-nop inits. Any code emission that tries to create a global init fn with contents will fail to compile.

In D135799#3855419, @ldionne wrote:

I think it would actually be better to define #define _LIBCPP_ENABLE_ASSERTIONS 0 at the top of the file. That way, we (1) retain the ability to use std algorithms, and we don't risk someone else breaking this in the future. WDYT?

In D135446#3852105, @bader wrote:

@urnathan, sorry, we didn't notice that https://reviews.llvm.org/D130909 introduces divergence. @steffenlarsen, @jcranmer-intel, FYI.
Regarding dropping LLVM_ prefix from header guards, it looks like these were removed with some automatic tool (https://github.com/intel/llvm/commit/c13a09a462807936f9eb17cc64f53ad7c9e8ddec), so I would expect someone else will run the tool again and add them back. Any ideas how to prevent this type of changes in the future? Maybe we can keep LLVM_ prefix for sources in llvm/ directory and just ignore this difference. What do you think?

This is ok, but see the note I added about object-file compatibility.

I'ma gonna replace the call to lower_bound in the demangler. https://github.com/llvm/llvm-project/issues/58117

Does this still apply with the fix for dr2621 landed?

this updates adds a map to record the active headers -- searching up the include stack is going to be O(N) per include, so not the best approach.

Ah, I should have investigated how it goes to find an existing lexer, it didn't occur to me that there already was include stack walking code.

ping pingedy ping?

Here's an update, just to check I've got all the comments addressed. It doesn't appear this DR has made it to the ready status in cwg-index, so ./make_cxx_dr_status barfed.

Richard & I discussed this, and decided it was a bad idea, as it means we could have an O(N^2) initialization walk, rather than O(N).

Wha? That seems rather concerning. What does getKind() return? (We assert that the kind is correct when trying to get the data out of the object, but perhaps you weren't using an asserts build?)

I forgot I had a git abbriev for the -U9999 thing, sorry about that.

AFAICT the UsingDecl doesn't capture the NestedNameSpecifier location, is UsingEnumDecl special in some way, or would this information be better placed in BaseUsingDecl? Thanks for spotting the possible mid-air collistion with D134283.

Might be mooted by fixing https://github.com/llvm/llvm-project/issues/57659, which I am working on

how can I get libc++abi review here?

please sed /initialiser/initializer/, I noticed a few had crept in.

ping?

LGTM

renamed test case

update

Please clarify. This is fixing a bug where the CFG was being incorrectly constructed.

ah, thanks for the clue!

hm, let's try that rebase again

LGTM,

Address CI issue

rebase

good to go, thanks!