Any update on this patchset? With the migration away from phabricator, it'd be good to get this in soonish (otherwise it'll need to be moved to github).

Depends on D158662

Just to note that we've gotten things to run based on this patch, so from our POV it would be good to merge this, and perhaps even backport it to 17.0.x

35bit -> 32bit?

Typo

In D129635#4451189, @saiislam wrote:>

Are there any features in this table which have been already implemented but have not been tagged?
https://clang.llvm.org/docs/OpenMPSupport.html#openmp-5-1-implementation-details

In D129635#4440613, @animeshk-amd wrote:

In the multi-company community meeting, the agreement was to move to the 5.1 version assuming that these features are supported.

Does this merit a mention in the release notes?

Does https://clang.llvm.org/docs/OpenMPSupport.html need an update? It still says "Clang fully supports OpenMP 4.5" (with many 5.0/5.1 features marked as "worked on" / "unclaimed"), which would make it unusual to put the default on a version that's (according to that status page) only ~30% implemented.

Mark P2615 as implemented in https://github.com/llvm/llvm-project/blame/main/clang/www/cxx_status.html?

Bunch of places where you're currently timetravelling. ;-)

FWIW, Microsoft's STL has ingested the boost implementation for the special functions for close to 2 years already (before that it needed to be installed by the user).

Old CMake mentioned in llvm-owned files:

• https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/LLVMCheckLinkerFlag.cmake#L8
• https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/AddLLVM.cmake#L2199

Two more mentions of old CMake in https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/SparseTensor/IR/CMakeLists.txt

In compiler-rt there's still a work-around marked TODO(dliew) here

Is this aiming to be exhaustive? For example, there's some still left in libunwind/src/CMakeLists.txt, as came up in https://reviews.llvm.org/D151344

And thanks for picking up & executing this idea! :)

How many times is that dance going to be necessary? I presume the respective owners have been given notice each time?

In D148928#4289619, @Mordante wrote:

No not really. Some information is here https://libcxx.llvm.org/Status/Format.html (dependency "A <chrono> implementation"). I know there are no parse functions too. However I haven't spend time investigating the exact status. I still intend to work on chrono in the future, at which time I probably will create a status page. But for now I'm focusing on format and modules.

Is there anywhere where the missing <chrono> bits are tracked? I tracked down the "In progress" status for P0355 on https://libcxx.llvm.org/Status/Cxx20.html back to https://github.com/llvm/llvm-project/commit/ebff3123a2d7c6b3d74d27c50700f0582ec45e85, but that's a long time ago.

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.