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?
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 (github.com)).
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.
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
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.
Sure, sorry for the terminology, Iām probably too deep in the C++ committee.
Papers:
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 clang.llvm.org/cxx_dr_status.html ā 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
Body:
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.
@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ā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.
|