Open dtarditi opened 4 months ago
BTW, C doesn't evolve that fast and the C front-end does not have that many bugs. The upgrade overhead here is mostly due to working in a shared C/C++/Objective C front-end code base.
We are closing in on the upgrade. I've fixed a number of merge issues that result in failing clang tests. Here is the summary of my latest run on a Windows x64 system using the 17-init-main branch:
Testing Time: 5371.27s
Skipped : 30
Unsupported : 237
Passed : 32974
Expectedly Failed: 39
Failed : 458
357 of the failing tests are for the 3C tool, which leaves 101 other failing clang tests.
We need to upgrade the Checked C clang sources to a newer version of clang. The Checked C clang source are currently based on clang 12.0.2, from Jan. 2021.
I updated the Wiki page on upgrading the compiler sources to point the most recent documentation on this.
I looked at clang 16.0 from July 2022 and clang 17.0 from Jan. 2023. In both cases, I merged the Checked clang sources into a baseline branch that matches upstream. I then committed the changes with the merge markers and diff'ed the two versions with merge conflicts. It does not look like much more work to jump to clang 17.0 instead of clang 16.0. There were only 95 merge chunks that differed between the two (and these could be because upstream changed relative to itself).
We will aim from clang 17.0. I've pushed two branches: 17-init-baseline, which just mirrors upstream at the point where the branch for 17.0 was a taken and 17-init-main, which has the Checked C clang sources merged into. We always smaller changes (the Checked C changes) into the clang sources (which have much more changes).
If you look at dates, we will be updating to 2 years of changes. This is about 2/3 of the time delta. This seems look a reasonable mid-point to aim for.
I am tracking progress on resolving the merge conflicts with the following files:
The current work is to resolve merge conflicts and get clang to compile again. The approach is to: