Oof... thank you for looking into this, but this is also pretty gross/fragile. Are we *sure* we want to do this? This is the only project I work on that treats CMake as an LTS-like thing, and I would be utterly shocked if this was the only optional feature that found itself needing a newer CMake for basic things. Do you happen to know which CMake version this workaround is not needed for (I knew at one time but have forgotten)?

Otherwise LGTM. Thank you again! :)

In D129025#3631057, @efriedma wrote:

I think we need to clarify LangRef if this is illegal in general for tokens in general. If it is, we need to explain why. If it isn't, we need an attribute the express the right semantics here.

All LangRef really says at the moment is that a token can't be put behind a phi or select; it doesn't really describe if/when it's legal to merge instructions that produce tokens.

ping now that MSVC build succeeds

Thanks for the fix.

LGTM
@maksfb Please take a look :)

LGTM

In D129089#3630961, @maksfb wrote:

@michoecho, thank you for the investigation and the patch. Both changes look good to me.

@yota9, @Elvina, great. Could you submit a patch with __atomic_test_and_set()?

In D129065#3631052, @jrtc27 wrote:

Commit subject/body should say C++ in it

In D128927#3622793, @ldionne wrote:

@mstorsjo I might need some assistance figuring out what to do with the Windows parts of this change.

Posted an update in rGa6e63e35ede4, which removes the not-fully-implemented RTTI bits, and adds an extra test case to cover instantiation errors.

I missed my opportunity to review while being on vacation last week. I reviewed to keep myself informed; spotted a typo.

• Use Process::GetSTD{OUT,ERR}

There was a merge conflict on the release notes, updating the differential to get a CI build.

Thanks!

I similar RFC for this was proposed here: https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606