GitHub Milestone/Project for C++20 implementation in clang


Would it be useful to anyone to have a GitHub Milestone/Project to track C++20 status in clang? I was thinking we could create an issue for each C++20 feature and then add them to either a Milestone or a Project (maybe even both). I have some interested in improving C++20 support in clang, but I never know who is working on what. I think having issues and tracking them might help with this and also make it easy for new contributors to see what features need to be worked on. What do you think?



Hi Tom,

That’s certainly a good idea.
Tracking features of C++ standards (both for clang and libc++) would be great.
It’s used in e.g. MSVC STL, and it works great (cf. Projects · microsoft/STL (


1 Like


It should be a good idea. I think it would be a great help if there is a roadmap to tell what is more emergency to do next.

I’ve heard people complaining that the support for C++2X of clang is behind of GCC…

I think it’s also a great idea, I’ve certainly heard Jason and Rob complain about it in a couple of CppCast episodes!

We should remember that “clang-format”'s support of C++20/C++23 features is also an important step.

Until fairly recently (v14) clang-format frankly butchered modules and co-routines, and although improved we are still juggling some issues with concepts.

Projects that are using clang-format, it could be clang format itself that could sometimes prove a barrier for entry to those new standard features and although they can use // clang-format on/off comments, that’s not a nice user experience.

Aaron and I have been trying to work on C++20/C23 support as our primary jobs, Aaron mostly working on constexpr, and myself trying to work on Concepts when I can (though slow going due to my lack of knowledge of template instantiation). I believe that ChuanqiXu has been working extensively on Modules.

One thing I will say, is the big hold up is as always, getting well informed reviewers available to help. There are quite a few open reviews with implementation of C++20 features that are unfortunately dormant due to lack of informed reviewers.

I think it could be real help. I’ve seen complaints as well, and having an up to date milestone target showing what still needs to be done might even help attract resources (contracting or FTEs from interested parties) to help move it forwards.

+1, there’s also interest for libc++ to look into this feature. We’ve discussed it both on Discord and in RFC: Create tickets for open libcxx papers/issues? · Issue #52642 · llvm/llvm-project · GitHub.

1 Like

I think it would be helpful too, I have been implementing a few things and I’m always a bit concerned that we might do duplicate work, although I’m mostly trying to do C++23 things at the moment. But i have some half started concepts-related branches too :slight_smile:

1 Like

Here is an example issue of what I had in mind.

I thought it might be good to put some yaml at the bottom to make it possible for scripts to parse the issues and create reports or status pages. I’m open to other suggestions for how to do this too.

Does it require the paper number? I mean C++20 papers should be merged in already. Might it be more simple to cite the wording directly? Like: [module.interface]p6: [module.interface]

Do we collect bugs? For example, the key problem in current coroutine implementation is on the optimization side. Almost all the feature in the C++20 standard is implemented from my personal perspective. So I want to ask if this would be collected? If yes, how?

An issue by plenary core motion is probably the simplest and less confusing.
There will be a paper for moved issues, that can be split further if need be.

Can you give examples of this? I’m not familiar with this terminology.

Sure, sorry for the terminology, I’m probably too deep in the C++ committee.


  • Once approved, we reflect it on the WG21 GitHub - Issues · cplusplus/papers · GitHub That query should have all the core approved c++23 papers

  • core issues: At the same time we vote on paper, we accept all the issues, and that’s usually a single paper Core "ready" Issues

On the other hand, there is already this page for issue – and i think this one is updated semi automatically, which means only issues that are require enough work to warrant a ticket should get one? Starting with papers might be easier.

@cor3ntin : I believe what Tom’s looking for (and me too) is what you think the structure of such a family of issues would look like. What would be the subject line of such an issue? What would be the body/description? There’s a huge difference between

Subject: Implement Oct 2021 plenary motion 5


Subject: Implement P1234 “Better fooing for barable bazzes”
Body: See , voted into the working draft in Oct 2021 (https : //wg21 . link/n4444 plenary motion 5); the exact changes are in P2415R2 What is a view? by jensmaurer · Pull Request #5010 · cplusplus/draft · GitHub

Filing an issue like the latter is more useful but also more tedious for the filer, which is why I didn’t even bother looking up a real issue — but I think it would be useful for whoever-is-doing-this to look up a couple real issues and propose how they would get filed, exactly.

Also, propose an organization scheme: GitHub Project? Subtask/supertask (if GH permits that)? One big label for “standardization work”? One label per meeting, like “Oct 2021 plenary”, “Oct 2022 plenary”…? One faux-supertask and then make sure each issue includes a mention of the faux-supertask number so that they all end up hyperlinked from there?

FWIW, I also think that filing GH issues for merged papers and resolved LWG issues would be helpful to libc++; but having just gone through our list of open C++2b LWG issues and realized how many of them are complete no-ops from the implementor’s POV (because they fix only bugs in the English or semantic requirements, not in the code), I remain ambivalent about the idea of filing a GH issue for every LWG issue. But I’m also ambivalent about the idea of leaving it up to one person’s judgment whether to file an issue or not. :slight_smile:

| Quuxplusone
January 25 |

  • | - |

@cor3ntin : I believe what Tom’s looking for (and me too) is what you think the structure of such a family of issues would look like. What would be the subject line of such an issue? What would be the body/description? There’s a huge difference between

We vote on papers, one issue per paper with the name of that paper, effectively reflecting cxx_status.html

Yes, this is what I’m trying to determine. I just want a standard structure, so I can start creating issues that will make sense to the people looking at them.

I think the useful informations are:

  • link to the paper
  • whether it is a defect report
  • whether there are dependency to another paper

And… that’s it?

You can look at what MSVC is doing for their library papers tracking P2441R2 `views::join_with` · Issue #2538 · microsoft/STL · GitHub

1 Like

OK, thanks, I will create some issues with that info and then and setup the milestone.


I’ve created the C++20 milestone and added issues for each c++20 feature marked as ‘No’ on the cxx status page.

I also submitted a patch to add links to these issues in the status page along with a template and instructions for creating new feature tracking issues. Additionally, I added some javascript to the page to automatically update the status table to say “In Progress” when one of the tracking issues gets assigned, and to update it to “Clang ToT” when the tracking issue is closed (you still need to manually update the table to add the clang version the feature first appears in).

If you are working on one of these features, please assign it to yourself, and we can use these issues for communicating progress.


What about CWG issues? Since they represent a well-defined unit of work, it’d be a good fit for issues as well, IMO.

Also, Clang ToT == “tip of tree”? Would it be possible to pull in the currently-in-development major number?