In D109593#3014343, @mstorsjo wrote:

In D109593#3013819, @ldionne wrote:

That is fine with me.

I want to standardize around exactly two types of supported builds:

1. Using <root>/runtimes as a CMake root.
2. Using <root>/llvm as a CMake root and mentioning LLVM_ENABLE_RUNTIMES=..... That is effectively bootstrapping Clang and building the runtimes with the just-built compiler.

In particular, I want to remove the ability to use <root>/llvm as a CMake root and say LLVM_ENABLE_PROJECTS=libcxx,libcxxabi,libunwind as a way of building, since that has a bunch of problems.

Are we on the same page? If so, we'll also want to improve on the terrible terminology we have today. (2) is currently called a "runtimes build", and (1) has no name. I would suggest we call (1) a "build of the runtimes", or just a "normal build", and that we rename (2) to a "bootstrapping build" or something like that.

That sounds like a good general direction. Distributors of llvm and the runtimes are going to need a decent sized transition period though.

For people using LLVM_ENABLE_PROJECTS, I would believe it should be straightforward for them to migrate. The bigger disruption is going to be when/if we stop allowing building the runtime projects entirely on their own by pointing cmake directly at e.g. libcxx. Judging from last weeks LLVM Distributors Conference, I would say that's the way a majority of distributors build it today, and transitioning that into e.g. 1. above will take some effort in the more complex cases. And some of them build this way with standalone source dirs without the surrounding monorepo, e.g. cc @tstellar.

In D109593#3012195, @mstorsjo wrote:

@phosek - What do you think of the rest of the changes left here in this patch now - do they seem sensible? Should I split them out to one to three more individual changes for the runtimes build (moving setting LLVM_RUNTIMES_BUILD to llvm/runtimes, including llvm-lit when necessary, making sure LLVM_INCLUDE_TESTS is on by default)?

Updating D110209: [CSSPGO] Set PseudoProbeInserter as a default pass.

In D110209#3014334, @MaskRay wrote:

lld/test/ELF/lto/pseudo-probe-lto.ll needs update

In D109593#3013819, @ldionne wrote:

That is fine with me.

I want to standardize around exactly two types of supported builds:

1. Using <root>/runtimes as a CMake root.
2. Using <root>/llvm as a CMake root and mentioning LLVM_ENABLE_RUNTIMES=..... That is effectively bootstrapping Clang and building the runtimes with the just-built compiler.

In particular, I want to remove the ability to use <root>/llvm as a CMake root and say LLVM_ENABLE_PROJECTS=libcxx,libcxxabi,libunwind as a way of building, since that has a bunch of problems.

Are we on the same page? If so, we'll also want to improve on the terrible terminology we have today. (2) is currently called a "runtimes build", and (1) has no name. I would suggest we call (1) a "build of the runtimes", or just a "normal build", and that we rename (2) to a "bootstrapping build" or something like that.

According @ldionne's plan, this patch would sleep 2 releases.

lld/test/ELF/lto/pseudo-probe-lto.ll needs update

Address @ldionne 's comments.

Thanks for creating this more comprehensive revision. Comments below.

Is this ready for review?

Remove the issue about [coroutine.handle.compare] in SpaceshipProjects.csv.

change for loop to internal_memset

Address comments:

• copy <experimental/coroutine> to <coroutine> and apply the change before.
• Move the components in <coroutine> out of std::experimental namespace. This requires D108696.
• Duplicate all the tests for <coroutine> to test the non-experimental version.

remove unnecessary parent revision

use real types for the callbacks