Thanks for upgrading the Google benchmark library!

@thieta are we still waiting on more reviews? Or could this be shipped?

Address comments

Thank you! LGTM

Thanks for looking into this! LGTM.

Just skimmed over it. I do not know enough about std::print for an in-depth review, hence just a couple of typos

Thanks a lot for all the work you have put into implementing std::format and std::print! It's amazing to see this coming together!

In D155397#4506191, @ldionne wrote:

Did you find that with fuzzing?

clang-format

not sure if I got the right audience of reviewers here. Please let me know if you think someone else would be better suited to review this

also fix ModuleSummaryIndex.h

@H-G-Hristov unfortunately, I don't know when I will find time to come back to this (and https://reviews.llvm.org/D132265). Feel free to take this over, if you are blocked by it

still need to fix CI

Guard against ADL

Remove trailing whitespace (hopefully fixes CI)

Thanks for this change!

Fix CI

The release notes should be added to libcxx/docs/ReleaseNotes.rst as "reStructuredText", in the form of a new bullet point. I guess this point would best fit into the "Improvements and New Features" section. Please make sure to point out in the release notes that this improvement shipped in the libcxxabi and not libcxx

LGTM

Nice! The CI is green again :)

Incorporate feedback received for similar review (list instead of vector; https://reviews.llvm.org/D132312)

Address review comments

@Mordante with D131395 landed, this should now be unblocked :)

Landing despite red CI, because:

• clang-format is red because it is complaining about incorrectly formatting in a pre-existing file
• "Apple back-deployment macosx-10.15" is failing due to some unrelated infrastructure error
• clang-cl failed due to std/thread/thread.mutex/thread.mutex.requirements/thread.timedmutex.requirements/thread.timedmutex.recursive/try_lock_for.pass.cpp which is unrelated to this commit

fix clang-tidy by replacing declval with std::declval

Add test for __debug_three_way_comp

Rebase on main; update status pages: 16.0 -> 17.0

Is this blocked on anything?

Should there be a Release Note added for this significant performance improvement?

@labath @aprantl Thanks for your reviews! I would like to backport this fix together with the fix from https://reviews.llvm.org/D132815 to the 16.0 release branch now. For that I would need your approval on https://github.com/llvm/llvm-project-release-prs/pull/254

Agree, other pretty-printers also don't use ASTImporter. I think the call was still needed originally in https://github.com/llvm/llvm-project/commit/01f4c305fae9ff2f165ce0f635a90f8e2292308c, because the promise_type was combined with newly created AST types which were created in a different AST-instance (see GetCoroutineFrameType in this old version of the code). My interpretation now is: Building struct types which refer to types from other AST instances is not supported. Returning synthetic children with types from different ASTs is supported, thoguh.

This change makes me a little nervous, but mostly because I don't quite understand the design here.
So ASTImporter does not have a check whether src context and dst context are identical?

Since I am still blocked on solving the Apple-specific issues in https://reviews.llvm.org/D132735 and couldn't solve them in time for LLVM-16, I now rebased this change directly on main, so that it no longer depends on the refactorings from the other commit.

fix crash in cases where the promise type is unknown even after an attempt at devirtualization

• 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...