Skip to content

Allow C17 for newer CMake versions#1958

Merged
Dead2 merged 5 commits intozlib-ng:developfrom
alxvth:patch-1
Sep 11, 2025
Merged

Allow C17 for newer CMake versions#1958
Dead2 merged 5 commits intozlib-ng:developfrom
alxvth:patch-1

Conversation

@alxvth
Copy link
Copy Markdown
Contributor

@alxvth alxvth commented Aug 29, 2025

The C17 standard is available since CMake 3.21. Since it pretty much just contains a couple of defect reports, it's probably save to allow it here.
At a quick glance I couldn't find a specific reason why C17 should not be allowed, but maybe there is something?

I'm not familiar with the code base, so I'm not sure if it would be OK to also allow C23, as that version actually removes some features.

Summary by CodeRabbit

  • New Features

    • Optional support for building with C17 and C23 when using a modern CMake (users can opt in during configuration).
  • Chores

    • Configuration validation still restricts C standard choices to supported values and yields clearer errors for unsupported selections.
    • Continuous integration expanded to test C17 and C23 across multiple platforms and toolchains.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Aug 29, 2025

Walkthrough

Adds C17 and C23 to allowed C standards when CMake > 3.20 and expands the CI matrix to test C17/C23 across Ubuntu (GCC/Clang) and Windows (MSVC); existing CMAKE_C_STANDARD IN_LIST VALID_C_STANDARDS validation remains unchanged.

Changes

Cohort / File(s) Summary
CMake configuration
CMakeLists.txt
Keeps set(VALID_C_STANDARDS "99" "11"); conditionally appends "17" and "23" when CMAKE_VERSION VERSION_GREATER 3.20 via list(APPEND VALID_C_STANDARDS "17" "23"); CMAKE_C_STANDARD IN_LIST VALID_C_STANDARDS unchanged.
CI matrix
.github/workflows/cmake.yml
Expands GitHub Actions matrix to add jobs testing -DCMAKE_C_STANDARD=17 and -DCMAKE_C_STANDARD=23 across Ubuntu (GCC and Clang — including clang-15 for C17 and clang-18 for C23) and adds a Windows MSVC 2022 v143 Win64 job for C17; Clang/LLVM package lists added for respective jobs. No runtime/control-flow changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested labels

Build Env, Continuous Integration

Suggested reviewers

  • Dead2
  • nmoinvaz

Pre-merge checks (3 passed)

✅ Passed checks (3 passed)
Check name Status Explanation
Title Check ✅ Passed The title “Allow C17 for newer CMake versions” directly describes a core change of permitting the C17 standard when using more recent CMake releases, which matches the primary modification in CMakeLists.txt. Although the PR also adds support for C23 and updates CI workflows, the title clearly refers to an actual aspect of the change set rather than being off-topic or generic.
Description Check ✅ Passed The description explains why C17 should be allowed based on CMake support, references the relevant standards and documentation, and notes uncertainty about C23, all of which directly relate to the changes implemented in the pull request. It clearly discusses the decision context and links to relevant resources, demonstrating that it is on-topic and tied to the modifications made.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

  • Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
  • Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.


📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fd80606 and 9440921.

📒 Files selected for processing (2)
  • .github/workflows/cmake.yml (3 hunks)
  • CMakeLists.txt (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • .github/workflows/cmake.yml
  • CMakeLists.txt
✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
CMakeLists.txt (1)

24-26: Approve: C17 gate is correct; update documentation and CI to mention/test C17

  • README.md (line 19): change “Modern C11 syntax” to “Modern C11/C17 syntax”
  • CMakeLists.txt (lines 11–15): default C11 comment—add a note that C17 is now supported
  • CI workflows (e.g. .github/workflows/*): add a matrix entry for CMAKE_C_STANDARD=17
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 83a84fa and 10301d0.

📒 Files selected for processing (1)
  • CMakeLists.txt (1 hunks)

CMakeLists.txt Outdated
set(CMAKE_C_EXTENSIONS OFF) # Boolean specifying whether compiler specific extensions are requested
endif()
set(VALID_C_STANDARDS "99" "11")
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.21)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VERSION_GREATER_EQUAL - cmake >= 3.7, but zlib-ng require cmake 3.5.1+

I would suggest removing the C standard version check.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, it should be VERSION_GREATER 3.20 to work with 3.5.1 as well.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find anything on why the version check is there but assumed that it's there for some reason, so I didn't want to just take it out myself.

@mtl1979
Copy link
Copy Markdown
Collaborator

mtl1979 commented Aug 31, 2025

I don't see any reason why we shouldn't allow compiling with more recent C standard as we have already decided that we support at least 3 most recent compiler major versions. Removing features isn't an issue if there is a replacement that works at least as good as the currently used function or feature.

In most cases only extra addition we should require is adding the new C standard in new CI workflow, so we immediately know if there is breaking change.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (5)
.github/workflows/cmake.yml (5)

89-94: Fail fast if C17 isn’t honored: add CMAKE_C_STANDARD_REQUIRED=ON.

Prevents silent fallback to an older standard on some toolchains/CMake combos.

-            cmake-args: -DCMAKE_C_STANDARD=17
+            cmake-args: -DCMAKE_C_STANDARD=17 -DCMAKE_C_STANDARD_REQUIRED=ON

95-100: Treat C23 as experimental and require the standard.

C23 support is still evolving across compilers/CMake; keep the signal without failing the whole CI and enforce the requested standard.

           - name: Ubuntu GCC C23
             os: ubuntu-latest
             compiler: gcc
             cxx-compiler: g++
-            cmake-args: -DCMAKE_C_STANDARD=23
+            cmake-args: -DCMAKE_C_STANDARD=23 -DCMAKE_C_STANDARD_REQUIRED=ON
+            experimental: true

Also add at the job level (outside this hunk) to honor experimental jobs:

continue-on-error: ${{ matrix.experimental || false }}

437-443: Apply the same “require standard” guard for Clang C17.

Avoids unintended fallback when CMake/Clang mapping changes.

-            cmake-args: -DCMAKE_C_STANDARD=17
+            cmake-args: -DCMAKE_C_STANDARD=17 -DCMAKE_C_STANDARD_REQUIRED=ON

444-450: Mark Clang C23 as experimental and require the standard.

Clang-15’s C23 coverage is partial; keep CI green while still exercising it.

           - name: Ubuntu Clang C23
             os: ubuntu-latest
             compiler: clang-15
             cxx-compiler: clang++-15
-            cmake-args: -DCMAKE_C_STANDARD=23
+            cmake-args: -DCMAKE_C_STANDARD=23 -DCMAKE_C_STANDARD_REQUIRED=ON
             packages: clang-15 llvm-15 llvm-15-tools
+            experimental: true

Remember to set (outside this hunk):

continue-on-error: ${{ matrix.experimental || false }}

544-548: Optional: require C17 on MSVC too.

MSVC maps C standards differently, but this keeps behavior consistent across jobs.

-            cmake-args: -G "Visual Studio 17 2022" -A x64 -T v143 -DCMAKE_C_STANDARD=17
+            cmake-args: -G "Visual Studio 17 2022" -A x64 -T v143 -DCMAKE_C_STANDARD=17 -DCMAKE_C_STANDARD_REQUIRED=ON
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 2e8cb20 and c278397.

📒 Files selected for processing (2)
  • .github/workflows/cmake.yml (3 hunks)
  • CMakeLists.txt (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • CMakeLists.txt

@alxvth
Copy link
Copy Markdown
Contributor Author

alxvth commented Sep 1, 2025

I added some CI workflows for C17 and C23, please adjust them as necessary.

Edit: I just noticed that clang-15, which is used in the CI, does not know C23 yet (only C2y), see this example on godbolt.

@mtl1979
Copy link
Copy Markdown
Collaborator

mtl1979 commented Sep 4, 2025

Latest MSVC version is too old to have C23 support, but there is chattering about new MSVC release near November 2025... We should see added features when first public betas are available... What comes to the added CI workflows, we can comment on them after they have been approved and finished running. Basically we need to look for any failed tests, be it a busy or idle loop, crash, checksum mismatch, or data corruption.

@codecov
Copy link
Copy Markdown

codecov bot commented Sep 7, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.60%. Comparing base (4cbe948) to head (9440921).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1958      +/-   ##
===========================================
+ Coverage    81.58%   81.60%   +0.02%     
===========================================
  Files          163      163              
  Lines        14073    14074       +1     
  Branches      3165     3166       +1     
===========================================
+ Hits         11481    11485       +4     
+ Misses        1625     1612      -13     
- Partials       967      977      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Dead2
Copy link
Copy Markdown
Member

Dead2 commented Sep 9, 2025

@alxvth Could you please rebase this PR? Bunch of CI fixes have gone in :)

@alxvth
Copy link
Copy Markdown
Contributor Author

alxvth commented Sep 9, 2025

Rebased, the branch is up-to-date again

Copy link
Copy Markdown
Member

@Dead2 Dead2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Dead2 Dead2 merged commit 7800569 into zlib-ng:develop Sep 11, 2025
155 checks passed
@alxvth
Copy link
Copy Markdown
Contributor Author

alxvth commented Sep 12, 2025

Thanks!

@Dead2 Dead2 mentioned this pull request Nov 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants