Tested this patch in https://github.com/conda-forge/llvmdev-feedstock/pull/198, can confirm it works. Thanks a lot!

Just to confirm: I applied this patch to rc1 (& rc2) and then things build fine again. Thanks!

Thanks for this!

In rG12cb1cb3720de8d164196010123ce1a8901d8122#1167403, @erichkeane wrote:

Urgh, REALLY!? This is a revert of a serious memory regression. I think I'll need some level of more information? I'm not sure what is going on with it? @ChuanqiXu is one of my modules code owners, and perhaps sees something obvious?

Cool!

Why abandon this revision? Wouldn't it be useful for this issue to have more visibility rather than less?

Sorry for the misleading and thanks for the quick clarification. So it looks like the status quo is a little bit worse than I imaged...

In D137534#4055283, @ChuanqiXu wrote:

@h-vetinari said it should be OK to backport these patches to branched 16.x.

BTW, the series of clang-scan-deps patch (https://reviews.llvm.org/D139168) is also necessary [...]

Without undue haste, I just wanted to comment from the peanut gallery that it would be amazing if the patches that are necessary for CMake + Clang to use C++ modules would make the cut-off for LLVM 16 that's coming up around the 24th of January.

Clang trunk doesn't claim support: https://godbolt.org/z/hes3nah8s. I'm actually quite surprised this doesn't break the CI. I remember having problems with at least Clang 15 when trying to use conditionally trivial special member functions.

I've had a small nit/suggestion post-merge of https://reviews.llvm.org/D138901; in case you feel it's worth picking up if you're touching that file already.

I'd also use newlines more liberally since the two-space indentation is pretty dense already.

@nadiasvertex
Any update on this?

Congratulations for landing this!

Drive-by comments for consistency

Seems DR2621 is not yet listed in https://github.com/llvm/llvm-project/blob/main/clang/www/cxx_dr_status.html (but if it were, it should be updated...)

Now I'm wondering why the attribute exists at all. If it's functionally equivalent to constexpr as a keyword, what are the use cases for the attribute?

In D133853#3797598, @RIscRIpt wrote:

I am afraid it would take me some effort to implement semantics of [[msvc::no_unique_address]], so I'd like to focus only on [[msvc::constexpr]] in current patch.

In D131388#3748062, @ChuanqiXu wrote:

Replace C++20 Modules with Standard C++ Modules since @ruoso pointed out that Modules is not specific to certain versions of C++ (for example, Modules may get some big changes in C++23, C++26, ...).

I have another question, probably mainly for @tstellar (since I don't understand the clang/tools/libclang/libclang.{exports,map} infrastructure). Now that we're defaulting back to the equality case, would we need to reinstate libclang.exports (probably conditional on CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION == ON)?

My concerns have already been raised by others in that thread and related issues, I see no point in restating them yet again. I don't see consensus, I see a handful of people discussing reverting a change that broke a whole bunch of assumptions made by real-world code.

Thanks for the review. Given that you have concerns, could you voice them in a larger forum (https://discourse.llvm.org/t/rationale-for-removing-versioned-libclang-middle-ground-to-keep-it-behind-option/64410), where so far the direction was in favour of going back to the status of LLVM 14 (but with an opt-out for those who prefer equality).

IMO looks good, thanks!

Sorry it took me a while to respond, was AFK last week. This looks like a good start, I can try testing the instructions with the LLVM 15 builds (also RCs) and report back with what I find.

In D129160#3716826, @isuruf wrote:

Maybe this should be a cmake option that is off by default and I can turn it for my builds?

LGTM

Are the rowspans here correct? For some reason https://clang.llvm.org/c_status.html is not being updated with this change.

Thanks! Repeating a point that might have been overlooked from D131062 (this time not as comments in the diff to avoid the "pollution" that caused the move to this PR):

If you do open a new revision, please also consider breaking the lines at a length that phabricator doesn't overflow (seems to be 122 characters), and change all occurrences of "codes" to "code".

If you do open a new revision, please also consider breaking the lines at a length that phabricator doesn't overflow (seems to be 122 characters), and change all occurrences of "codes" to "code".

In D131062#3705864, @ChuanqiXu wrote:

Yeah, I am also worrying if the comments may block other reviewers to review. Do you know any method to ignore these comments in phab? If not, I guess I need to create a new page (but this is what we want?)

It gets very confusing that phab now attaches the old review comments in the wrong place.

It would be greatly welcome for such comments!

That was the last algorithm in RangesAlgorithms.csv - congratulations! :)

Aside from a couple typos, I was wondering if it would be welcome to do a pass w.r.t stylistic improvements (e.g. "Modules have a lot of meanings." --> "The term 'modules' has a lot of meanings"). I don't want to be too nit-picky - the sentences are all understandable, but sometimes slightly unusual to a native speaker in their formulation.

There are still a few tests for these commented out, e.g. in:
libcxx/test/std/algorithms/ranges_robust_against_dangling.pass.cpp
libcxx/test/std/algorithms/ranges_robust_against_proxy_iterators.pass.cpp
libcxx/test/std/library/description/conventions/customization.point.object/niebloid.compile.pass.cpp

Thanks for chasing these down!

Tested that this fixes the issue - thanks!

My point boils down to: "written using standard C++17
code" does not sound at all like "core language, no stdlib", but very much like "core+stdlib".

From the text you quoted:

It may be worth calling out that this is about C++17 core language and not the standard library?

The commit landed after LLVM 15 branched but still mentions that version in the release notes & CXX status. Is the intention that this'll be backported?

In D129160#3678431, @tstellar wrote:

@h-vetinari Does the release note look OK?

How realistic is it that this still makes it into LLVM 15? I'd really like to start testing the pstl in our ecosystem a bit, happy to file bug reports too if so, but I'd need a way to be able to build it...

Is it realistic for this to land before LLVM 15 branches? Would be great!

In D129195#3652046, @philnik wrote:

In D129195#3650796, @h-vetinari wrote:

Though you probably know, there's yet another DR on top of P1423 that has been accepted (only missing plenary vote): https://github.com/cplusplus/papers/issues/1171

Might be worth investigating to not needlessly introduce breakage that will then have to be undone again.

The paper you linked only changes core wording, so it shouldn't make any difference for the library part. Or am I missing something?

Though you probably know, there's yet another DR on top of P1423 that has been accepted (only missing plenary vote): https://github.com/cplusplus/papers/issues/1171

We're currently focusing on ranges to get as much as possible into LLVM15. After that I want to work on std::pmr.

This PR didn't update the format status page. Is the warning from C++20 status still current?

P0645: The paper is implemented but still marked as an incomplete feature (the feature-test macro is not set and the libary is only available when built with LIBCXX_ENABLE_INCOMPLETE_FEATURES). Not yet implemented LWG-issues will cause API and ABI breakage.

Any update on this?

Just comments, looks OK otherwise.

Forgot to mention it before: would be good to note this in the release notes

Thanks for the ping. It's unfortunate that this didn't work out as intended. It's certainly fine though (for our purposes) to go back to the way things were before.

Should probably be mentioned in the release notes...?

Very happy to see this finally happening! :)

2x "Buffer cannot by nullptr" -> "Buffer cannot be nullptr"

Speaking as a relative outside (but who's been waiting for flang in LLVM since well before it joined the monorepo), I'd much prefer code-generation-with-rough-edges in LLVM 15 (to start testing and raising eventual bugs), rather than a more polished flang (realistically still with bugs that need to be shaken out) in LLVM 16.

Something must have gone wrong... communication-wise... as @urnathan seems to have abandoned (resp. resigned from) all modules PRs. Hope any misunderstandings or grievances can be worked out!

A non-actionable comment out of curiosity for the work

Just a nit/note before LLVM 14 branches: a few bullets in FormatPaper.csv should probably now be updated as well.

Congratulations on landing this huge piece of work, and even more so in time for LLVM 14!

Ah, just saw your comment to that exact effect in the meantime. :)

OK, just taking the second half of the patch in openmp/libomptarget/deviceRTLs/amdgcn/CMakeLists.txt is actually enough for the backport.

Thanks a lot for the patch! I'm trying to figure out how to apply this to 13.0.0-rc2, but it's not obvious since https://reviews.llvm.org/D111983 has happened in between and reshuffled a bunch of things around.

Given the cross-review of the respective authors, I'm assuming this is compatible / aligned with https://reviews.llvm.org/D111356? I ask because despite the mutual review, this wasn't mentioned in the email to LLVM-dev about the latter.

I tested this patch in https://github.com/conda-forge/llvmdev-feedstock/pull/131 and it works as intended. Any blockers to landing it?