• static_assert for signed integral
• add missing includes

I reapplied this patch locally on top of the latest main and tried to reproduce the issue on my Mac using

Seems like the failed unit tests are not related to this patch nor the parent revision.

Here is one of the error messages produced on Apple

Adress a couple of varconst's comments. Not completely done, yet. Want to get feedback from the CI

Ah, now I understand how you are planning to apply your changes. I assumed you first wanted to apply this patch, and then https://reviews.llvm.org/D138005 on top of it (i.e. first the refactoring, then the perf improvement). But you want to apply them exactly the other way around.

Thanks for looking into the performance of dynamic_cast and for splitting your initial patch from https://reviews.llvm.org/D137315!
Unfortunately, it looks like your patch is still not rebased onto current main. E.g., your patch claims to delete a couple of lines which are not currently on https://github.com/llvm/llvm-project/blob/main/libcxxabi/src/private_typeinfo.cpp. I marked one of those examples below. That's also why the CI currently fails (see "patch application failed" link further up on this page). Let's get that sorted out first, and as soon as the diff is correct, I will start reviewing your changes (I see little value in reviewing a non-applicable patch)

address varconst's commments

The issue with this change was that if devirtualization is failing, then in the line

As discussed via email, the reason for the test failures on green dragon is, that green dragon seems to be using some compiler which passes the test

• forward -> move
• move iterator initialization out of benchmarking loop
• remove #if _LIB_CPP_VERSION check from benchmark

@jasonmolenda I am a bit confused about your revert.
Did you indeed revert this change here? Afaict, you reverted https://reviews.llvm.org/D132735 and https://reviews.llvm.org/D132815, but left this commit in place. I did not actually read through your code changes, though, I only looked at the commit messages so far. Is my understanding of which commits you actually reverted correct?

• sort includes correctly
• work around NASTY_MACRO

• use explicit types instead of auto
• make benchmark runnable on non-libcxx

And now, it should be clear that why the coro_always_done and coro_always_resume is helpful for coroutine elision. Since it is helpful for such cases.

Interesting... . I will need to read up on coro_always_elide a bit before being able to form an informed opinion.
I found https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2594r0.pdf
Any other relevant resources?

Another try at fixing the CI; this time the benchmarks

add missing _LIBCPP_HIDE_FROM_ABI; use new test utility

add inline

Introduce reusable test function

fix CI... maybe...

fix CI

fix CI

fix CI

needs to be adjusted to use the still-to-be-introduced test utilities from https://reviews.llvm.org/D132312 is done

needs to be adjusted to use the still-to-be-introduced test utilities from https://reviews.llvm.org/D132312 is done

fix CI

I think I addressed all actionable review comments now.

Address mordante's comments about test cases:

Updated benchmark code to directly compare the slow and the fast path

@var-const As requested, I updated the benchmark to benchmark int* on both the fast and the slow path.

Sorry for the late reply - and thanks for your detailed answers!

Personally, I am fine with this change as in review right now.

@aprantl I still had to adjust the code slightly to copy the type from the ASTContext for '.../a.out' to the scratch ASTContext (without this, my code was triggering an assert).
See https://reviews.llvm.org/D132624?vs=474793&id=475327 for the related changes.
Because I have no prior experience with ClangASTImporter and the usage of multiple different TypeSystemClang instances, I would appreciate if you could take another quick look

Fix ownership of CompilerType between "scratch typesystem" and "module type system"

Pushed upstream. Thank you for the fix!

Can you provide me a git patch, including the meta data (email address, ...)?
Not sure how to get this from Differential, I am rather inexperienced with it myself...

LGTM, with small nit:

@labath @aprantl Thank you for your reviews on https://reviews.llvm.org/D132815 and https://reviews.llvm.org/D132735
I would appreciate if you also have time to review this change here, as it is a pre-requisite for the other two changes :)

@avogelsgesang Do you need anything from us to make progress on this patch? I'd like to make sure you're unblocked.

does it make sense to add a regression test?

rename IsNoopResumeDestroy -> IsNoopCoroFunction

wondering if we couldn't fix this by creating the (non-pointer) object using the CreateValueObjectFromAddress function, as above, but then actually use valobj->AddressOf as the synthetic child

address review comments

took a look at the documentation; didn't read the implementation itself

Agree, not a blocker

high-level design comment (I didn't look at the code; wouldn't understand it anyway):
I think there is another important case to cover, besides "a coroutine can only be destroyed after it ran to its final suspension point":
"A coroutine can only be destroy after it ran to its final suspension point *or* before it executed until after its initial suspension point"

Thanks for the quick fix!
I unfortunately don't understand this code here, and can't give you a review, though

Thanks for the quick review, @MaskRay!

My understanding is, that I am not supposed to merge to main until after I got approval from the libunwind review group.
Not sure how the priority of following those process requirements compare to the unblocking Gentoo testing. I am too new to LLVM to really make a call here...

@MaskRay and @compnerd could I get a review from you on this change, please :)

Thanks for those build instructions! I was able to reproduce the test failures.
The updated review now fixes the failures for me. Could you please double-check if it also fixes the failures for you?

remove assert completely

Thanks for checking this, @mgorny!
Well, I guess I will have to dig deeper, then...
Can you share a (preferably minimal) command line how to reproduce the test failures on a 64-bit Linux machine?

FYI: I suspect this change caused a compile-time regression from 60sec to >40 minutes for an interpreter-loop based on computed-gotos. See https://github.com/llvm/llvm-project/issues/57664

for what it's worth: As part of upgrading the Salesforce-internal clang toolchain to clang 15.0.0, I also ran into the RUNPATH issues. This patch here solved those issues for us

Are you planning to also replace existing usages of, e.g. #if _LIBCPP_STD_VER > 17 by #if _LIBCPP_STD_VER >= 20?

is there a reason why we add our own clang-tidy plugin instead of upstreaming this to clang-tidy itself? I could imagine that other library developers could also benefit from this clang-tidy check, if we make the list of allowed customization points a configuration option