[libc++] Use Github tools to track our Standards conformance

[ldionne]

This issue is a reboot of #52642.

Libc++ currently tracks its conformance status in CSV files that we update manually. Unfortunately, this is not very well integrated with the rest of our development workflows, which revolve around Github. This issue tracks the investigation to move from CSV files to Github issues (or milestones, or projects, or something else) for conformance tracking in libc++. This would provide the following benefits:

• Better integration with the rest of our workflows (e.g. issues closed automatically when landing a PR)
• Better ability to filter things in the UI via tags (e.g. show me all unassigned LWG issues that were included in C++20)

However, when we discussed it in the Libc++ monthly meeting on January 23rd 2024, we identified the following two requirements for this migration to be viable:

1. We need the ability to generate a status page for our documentation so that users can still see the status of libc++ on llvm.org. Users shouldn't have to go to Github and do some research to find this status.
2. We need to ensure that it's easy to find the status of a LWG issue or paper. Today we can basically just grep the codebase and we'll find the status via the CSV file. We should have an easy workflow accessible, for example by using the gh command-line tool.

We will also want to think about whether we want to migrate already-implemented issues to this system or not, and if so, how to automate it. It would sure be nice if all the current status pages were migrated over to GH issues so that we have a single place to search for everything.

[ldionne]

I looked into the searchability aspect of this, and I think gh got us covered. This is just an example:

% gh issue list --milestone 'LLVM 18.0.x Release'

Showing 6 of 6 issues in llvm/llvm-project that match your search

ID      TITLE                                                                                                  LABELS                                     UPDATED
#78068  cfi_ignorelist.txt doesn't seem to be installed                                                        cmake, clang                               about 2 days ago
#76273  Change library SONAMEs to include minor version                                                        cmake                                      about 1 month ago
#71161  [clang] Wrong SourceRange returned by getNameInfo() for template instantiations of CXXDestructorDecls  bug, clang:frontend, regression            about 7 hours ago
#69065  Assertion `Result.isAbsent() && "local created multiple times"' failed.                                clang:frontend, confirmed, crash-on-valid  about 3 months ago
#61881  [MIPS] Incorrect expansion of sub-word signed atomic max                                               backend:MIPS                               about 2 days ago
#60717  In a function with a `noundef` return value, replace `ret undef` with `unreachable`                    llvm:optimizations, missed-optimization    about 5 months ago

We can filter by tags, assignee, milestone, project, and a bunch more. I think that if we appropriately tag the issues representing DRs and papers, they would be easily searchable from the command-line, and in fact it would be a lot easier and more flexible than greping our source files.

[cjdb]

We will also want to think about whether we want to migrate already-implemented issues to this system or not, and if so, how to automate it. It would sure be nice if all the current status pages were migrated over to GH issues so that we have a single place to search for everything.

I agree. I do think this is secondary to getting the work items up, so that we can avoid duplication of work.

[ldionne]

As of right now, we have issues for all LWG issues and WG21 papers from C++14 to C++26. They are displayed in the following libc++ Standards Conformance project.

[h-vetinari]

This is really cool!

I played around with the board a bit, and noticed there's a handful of issues that don't have a label for the respective C++ version, meaning that they fall through the cracks on most of the views in the GH project.

I see that a bunch of them only target a TS (and library fundamentals v2 has a separate label), but at least #99960 should target C++17 AFAIU. In any case, might be worth to have a separate "TS" view so that these issues gain a bit more visibility?

[ldionne]

@h-vetinari Thanks a lot for the heads up! I had a look and tried classifying everything I could find. For now, I've associated a c++xx tag to all the issues based on when they were adopted, for example an issue showing up in Cxx17Issues.rst has the c++17 tag associated to it. It's not the only conceivable way to do things, but it seems like the simplest and most systematic way for now.

We could do as you suggest, but we would have to go through all the issues and label them properly (I'd suggest a single TS label to keep things simple), and then we could create a separate view in the project. I think that would work and it might be a better way to organize things, but it's also more work. Since we don't really implement TSes much, I wonder if there's sufficient value to justify it.

[h-vetinari]

Since we don't really implement TSes much, I wonder if there's sufficient value to justify it.

One benefit would be that they don't show up in the other boards as "things left to do until we achieve conformance"... :)