`scan-build` is a (Perl) wrapper around clang's built-in `--analyze`
option. Which look similar or identical to clang-tidy checkers under
the `clang-analyzer-*` namespace:
https://clang.llvm.org/docs/ClangStaticAnalyzer.html
Unless somebody has other information, it appears redundant to run
scan-build in parallel with clang-tidy in CI, now that the latter is
working reliably and with good performance for all curl components.
Another scan-build issue is the lack of a markup to suppress false
positives. It ignores `NOLINT`, yet finds the same false positives as
clang-tidy. This happens with scan-build v20+. v18 is silent, but it's
a blocker to upgrade to a newer version.
scan-build may still be a useful when combined with autotools, where
clang-tidy support is incomplete, slow (no parallelism), and uses
a distinct make target, which does not build binaries in the same pass.
But, scan-build also lacks extra checkers that are now enabled for
clang-tidy.
The clang-tidy job is also 30-40s faster than the one it replaced.
Also:
- drop scan-build job configured the same way as a clang-tidy one.
CI time saved: 6m30s
- bump to clang-20 (from 18) in the replacement job.
- build tests in the replacement job.
To verify a cmake command-line reconstruction issue only hit in this
job in CI.
CI time cost: 1m40s
- replacement job caught a minor, new, issue.
Ref: b2076d3c2f#20752
- drop unused scan-build logic.
Bug: https://github.com/curl/curl/pull/20732#issuecomment-3963873838
Ref: https://github.com/curl/curl/pull/20732#issuecomment-3967479228Closes#20751
Checking lib and src under 3m15s versus 7m15s.
Downside: autotools clang-tidy support is no longer CI-tested.
The reason for the slowness is invoking a single clang-tidy command with
all source files, and clang-tidy checking them in a single thread,
sequentially. clang-tidy offers a `run-clang-tidy` Python script for
parallel processing, which may help with this. However at this point
it's more practical to use cmake, which also supports verifying the
whole codebase, not only lib and src.
Also:
- bump clang-tidy to the latest available, v20 (from v18).
- enable running clang-tidy on tests. Takes under 2 minutes.
Also tried `_CURL_TESTS_CONCAT=ON`, it brings down the build tests step
from 1m47s to 54s, saving 1 minute. Skipped using it for now.
Closes#20725
Tests are build in "unity"-style, by including sources into an umbrella
C files (similar to how CMake unity works). This does not play well with
clang-tidy, which seems to unconditionally ignore C sources included
like this. To fix it, curl's CMake implements a manual clang-tidy
support for tests, which compiles sources one-by-one, while also making
sure sources compile cleanly standalone (e.g. all sources need to
include `first.h`). The manual clang-tidy implementation is fragile, and
performance, in particular when targeting Windows, is abysmal.
This patch introduces an alternate solution, enabled by the
`_CURL_TESTS_CONCAT=ON` option. In this mode, umbrella sources include
the actual sources instead of `#including` them. Allowing to use CMake's
built-in clang-tidy support to compile them, with clang-tidy actually
checking the sources. Making the manual clang-tidy support unnecessary.
In the Windows CI job it results in a 4x performance improvement (4m ->
1m), making it practical to run clang-tidy on tests on Windows, in CI.
The main downside is that clang-tidy doesn't understand the `#line`
directive. Meaning issues found show the wrong filename and line number
next to them. It's not impossible to locate errors this way, but also
not convenient.
Minor/potential downside is that the concatenated source needs to be
reassembled each time an original source is updated. This may result in
more copying on the disk when used in local development. The largest
source is 1.4MB, so probably not a show-stopper on most machines.
Another is the complexity of maintaining two methods in parallel, which
may be necessary till clang-tidy understands `#line`:
https://github.com/llvm/llvm-project/issues/62405
This solution may in theory also enable adding clang-tidy support for
tests in autotools, though I haven't tried.
Targeted for curl CI for now, and used in a GHA/windows job. 100%
experimental, not recommended outside these.
Closes#20667
Also:
- include code to verify a C++-specific public header regression
reported in 8.19.0-rc2.
- curl/curl.h: mention C++ global namespace in comment.
- GHA/dist: add CI job for C++. Runtime: 15 seconds.
Follow-up to ee9b000438#20686
Ref: #20682Closes#20687
Fix bigger and smaller kinks in how clang-tidy is configured and used.
Sync behavior more between autotools and cmake, lib/src and tests. Bump
clang-tidy minimum version and prepare logic to allow using clang-tidy
to a fuller extent.
- move clang-tidy settings from builds to a new `.clang-tidy.yml`.
To make it easy to see and edit checks at one place. Also to allow
using the `--checks=` option internally to silence tests-specific
checks. (clang-tidy does not support multiple `--check=` options via
the command-line.)
Use explicit `--config-file=` option to point to the configuration.
- .clang-tidy.yml: link to documentation.
- suppress `clang-diagnostic-nullability-extension` due to a false
positive in libtests with `CURL_WERROR=ON` and `PICKY_COMPILER=OFF`.
- .clang-tidy.yml: enable `portability-*`, `misc-const-correctness`.
- drop `--quiet` clang-tidy option by default to make its working a bit
more transparent. The extra output is minimial.
- consistently use double-dashes in clang-tidy command-line options.
Supported by clang-tidy 9.0.0+ (2019-09-19). Before this patch single
and double were used arbitrarily.
- src/tool_parsecfg: silence false positive `clang-analyzer-unix.Stream`.
Seen with clang 18 + clang-tidy 19 and 20 (only with autotools.)
- INTERNALS: require clang-tidy 14.0.0+. For the `--config-file` option.
- INTERNALS: recommend clang-tidy 19.1.0+, to avoid bogus
`clang-analyzer-valist.Uninitialized` warnings. (bug details below)
autotools:
- allow configuring the clang-tidy tool via `CLANG_TIDY` env.
Also to use in GHA to point to a suffixed clang-tody tool.
- fix to pass CFLAGS to lib, src sources.
(keep omitting them when using a non-clang compiler.)
- fix to pass `--warnings-as-errors=*` in quotes to avoid globbing.
cmake:
- fix to not pass an empty `-I` to clang-tidy.
- fix to pass CFLAGS (picky warnings) to clang-tidy for test sources.
(keep omitting them when using a non-clang compiler.)
- fix to disable `clang-diagnostic-unused-function` for test sources.
(tests have static entry points, which trigger this check when
checking them as individidual sources.)
- fix forwarding `CURL_CLANG_TIDYFLAGS` to clang-tidy.
- force disable picky warnings when running clang-tidy with a non-clang
compiler. To not pass these flags when checking lib and src.
CI:
- GHA/linux: avoid clang-tidy bug by upgrading to v19, and drop the
workaround.
- GHA/linux: switch to clang from gcc in the clang-tidy job. Using gcc
doesn't allow passing CFLAGS to clang-tidy, making it less effective.
(My guess this was one factor contributing to this job often missing
to find certain issues compared to GHA/macos.)
I recomment using clang-tidy with a clang compiler, preferably the same
version or one that's compatible. Other cases are best effort, and may
fail if a C flag is passed to clang-tidy that it does not understand.
Picky warnings are mostly omitted when using a non-clang compiler,
reducing its usefulness.
Details and reproducer for the v18 (and earlier) clang-tidy bug,
previously affecting the GHA/linux job:
clang-tidy <=18 emits false warnings way when passing multiple C sources
at once (as done with autotools):
```sh
cat > src1.c <<EOF
#include <string.h>
static void dummy(void *p) { memcmp(p, p, 0); }
EOF
cat > src2.c <<EOF
#include <stdarg.h>
void vafunc(int option, ...)
{
va_list param;
va_start(param, option);
if(option)
(void)va_arg(param, int);
va_end(param);
}
EOF
/opt/homebrew/opt/llvm@18/bin/clang-tidy --checks=clang-analyzer-valist.Uninitialized src1.c src2.c
# src2.c:7:11: warning: va_arg() is called on an uninitialized va_list [clang-analyzer-valist.Uninitialized]
```
Follow-up to e86542038d#17047Closes#20605
Previous tag v6 changed upstream and points to a different commit. This
made zizmor unhappy. Previous commit is now tagged v6.0 in case we need
it.
Closes#20591
Upgrade a GHA/windows job to VS2026 (from VS2022), using a runner image
released a week ago. It also comes with the same Windows SDK as VS2022:
v10.0.26100.0.
The runner image uses Windows 2025 unfortunately, which makes the job
run significantly slower than before this patch:
- configure: 49s -> 1m10s
- build: 3s -> 5s
- install test prereqs: 23s -> 27s
- run tests: 3m18s -> 4m11s
- build examples: 15s -> 25s
It's a shame.
Also:
- cmake: enable picky warnings for VS2026 internal version 19.50.
Build is clean with existing options.
- GHA/windows: make the built-in OpenSSH intall path recognize
the windows-2025-vs2026 image as windows-2025.
- windows-2025-vs2026 is able to load the cached stunnel made on
the windows-2022 runner.
- disk use of the build is almost identical to VS2022.
Before: https://github.com/curl/curl/actions/runs/21955482367/job/63418133880
After: https://github.com/curl/curl/actions/runs/21957589847/job/63426546943
Ref: 71f0157880/images/windows/Windows2025-VS2026-Readme.md
Ref: #20575Closes#20577
To simplify setting BoringSSL version, using:
`-DBORINGSSL_VERSION=0.20260211.0`
or
`-DBORINGSSL_VERSION=${boringssl_version}`
Previously it could be set via C flags, using complicated shell quotes:
`-DCMAKE_C_FLAGS="-DCURL_BORINGSSL_VERSION=\\\"${boringssl_version}\\\""`
(the C flags method remains, also for autotools)
It'd be nice if BoringSSL published its version not just via
`MODULE.bazel` in its source tree, but from its public headers, to make
these workarounds unnecessary.
Also:
- GHA/http3-linux: test both options.
Closes#20571
This package is automatically bumped, but needs manual intervention
anyway, to update gcc version number in the filename.
Follow-up to 4ad0a022e1#20517Closes#20523
- update `actions/checkout` from 6.0.1 to 6.0.2
- update `ruff` from 0.14.11 to 0.14.14
- update `cryptography` from 46.0.3 to 46.0.4
- update `psutil` from 7.2.1 to 7.2.2
- update `websockets` from 15.0.1 to 16.0
Closes#20490Closes#20491
Merging the two macOS jobs saves 4-5 minutes. The dropped iOS Ninja job
saves 0.5-1 minute. (Keep the two slow iOS jobs to maintain variation.)
Number of Apple jobs is 32 after this patch.
Also:
- skip building tests and example in iOS autotools to save 30-40s.
Closes#20467
It has been happening for a long time.
Example:
```
test 3001...[HTTPS localhost, last subject alt name matches, CN does not match]
3001: protocol FAILED!
There was no content at all in the file log/7/server.input.
Server glitch? Total curl failure? Returned: 56
== Contents of files in the log/7/ directory after test 3001
=== Start of file commands.log
../src/curl.exe -q --output log/7/curl3001.out --include --trace-ascii log/7/trace3001 --trace-time -4 --cacert ./certs/test-ca.crt https://localhost:64259/3001 > log/7/stdout3001 2> log/7/stderr3001
=== End of file commands.log
=== Start of file http_server.log
13:57:47.951283 Running HTTP IPv4 version on port 64256
=== End of file http_server.log
=== Start of file https_stunnel.log
2026.01.28 13:57:48 LOG5[ui]: stunnel 5.76 on x64-pc-mingw32-gnu platform
2026.01.28 13:57:48 LOG5[ui]: Compiled/running with OpenSSL 3.5.4 30 Sep 2025
[...]
2026.01.28 13:57:49 LOG5[0]: Service [curltest] accepted connection from 127.0.0.1:64281
2026.01.28 13:57:51 LOG3[0]: s_connect: connect 127.0.0.1:64256: Connection refused (WSAECONNREFUSED) (10061)
2026.01.28 13:57:51 LOG3[0]: No more addresses to connect
2026.01.28 13:57:51 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
=== End of file https_stunnel.log
=== Start of file server.cmd
Testnum 3001
=== End of file server.cmd
=== Start of file stderr3001
curl: (56) Recv failure: Connection was reset
=== End of file stderr3001
[...]
RUN: Unknown server on our https port: 64259 (56)
```
Ref: https://github.com/curl/curl/actions/runs/21440845836/job/61743268798?pr=20461Closes#20462
A cache entry created by windows-2022 is not picked up by
windows-11-arm. Also a cache created by windows-11-arm is not picked up
by windows-2022. Possibly related to this filed in 2025 June:
https://github.com/actions/cache/issues/1622. Also tried
`enableCrossOsArchive` to no avail. Unclear if these two runners count
as distinct operating systems, I'd guess not. Cache entries are
identical on the web UI. Via GH API they show up with the same cache key
bot different "version" (hash) and different sizes, possibly due to the
zstd vs. gzip bug above.
Fixing (identical error text on either runner):
```
Error: Failed to restore cache entry. Exiting as fail-on-cache-miss is set. Input key: Windows-stunnel-5.76-amd64
```
Also fix a silly typo in the shell value.
Follow-up to 0f54ca6150#20454Closes#20456
- set `CURL_DROP_UNUSED=ON` for Windows (MSVC) to make the analysis step
faster: 1m30s -> 1m15s
- enable `CURL_WERROR=ON` in all builds, to catch potential build issues
in addition to running CodeQL. To make these builds useful as regular
build tests too.
- add links to CodeQL Actions documentation.
- delete test data C files after checkout in an attempt to remove them
from CodeQL code coverage stats.
Closes#20418
Replace Chocolatey install with direct download and unpack. To reduce
CI dependencies (Chocolatey, NuGet), improve install performance
(10s -> 1s) and hopefully reliability. Last but not least to enable it
for the Cygwin CI job.
Caveats:
- Need to bump stunnel versions manually (2-3 times a year).
Renovate could likely do it, but I failed to understand its
documentation and miss tooling/interface to make tests.
- FIPS not enabled. (can be done if necessary)
- Possibly losing checksum verification (not sure if Chocolatey did it
automatically for this package.)
Also:
- Increase minimum tests by 100 for the Cygwin job.
Ref: #16819 (earlier attempt)
Ref: https://www.stunnel.org/archive/
Ref: https://www.githubstatus.com/incidents/cqb5hcy0gx18
Follow-up to d176f58a20#20413
Follow-up to 19b1e44660#20409Closes#20410
Bump CMake version in CMake integration tests for better performance
(8x on macOS, 2-3x on Windows) and native arm64 binaries.
- bump old CMake in integration tests to v3.19.8 (was: v3.11.4)
- switch to native arm64 CMake binaries on macOS.
- switch Linux CMake integration job to arm64.
Speed gains:
- Linux: 2m -> 1m30s
- macOS: 9-10m -> 1m15s
- Windows: 6-7m -> 2m43s
Before:
https://github.com/curl/curl/actions/runs/21255697172https://github.com/curl/curl/actions/runs/21255020621
After:
https://github.com/curl/curl/actions/runs/21272021446
With this, CI is:
- no longer testing deprecated CMake versions.
Follow-up to a7c974e038#19902
- not testing the next (from 2026 April) minimum 3.18, but going for
3.19 instead. For arm64 binaries on both macOS and Linux. There is
no 3.18-specific CMake code in curl.
Cherry-picked from #20407Closes#20408
To avoid unnecessarily installing Intel C for any `<pkg>-intel` locally
built dependency.
Follow-up to ab8ccaed24#20392
Follow-up to d9fe60d457#20248Closes#20400
To enable known linker options dropping unused, dead, code and data from
the executables built.
Useful to reduce binary sizes for curl, libcurl shared lib and apps
linking static libcurl. It's effective on both "unity" and non-unity
builds. Aligning "unity" build sizes with default, non-unity ones.
Supported platforms: Apple, MSVC, llvm/clang and GCC on all tested
platforms: Linux, BSDs, Windows, MSYS2/Cygwin, Android, MS-DOS.
Notes:
- Static libraries grow 20-30% with non-Apple toolchains.
This effect is controlled by separate, optional compiler flags on
non-Apple. This patch enables them automatically for public binaries
(libcurl and curl tool), and leaves them off for internal/test ones.
- MSVC enables this option by default for 'Release' configurations.
The curl build option has no effect on it.
- Observed effect on VS2010 is negligible. VS2012+ is recommended.
- Works with LTO, Fil-C.
- No observed/conclusive effect on build speed.
- On Windows with clang/gcc (mingw-w64/MSYS2/Cygwin) it also enables
`-fno-asynchronous-unwind-tables` as a workaround to make
the toolchain options actually work.
Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=11539
Thanks-to: Andarwinux
Also:
- GHA: enable in Linux and MinGW jobs to test it. Size changes:
- linux aws-lc H3:
curl: 2000000 -> 1937152, libcurl.a: 2065724 -> 2716532 bytes
- macos clang HTTP-only:
curl: 1364376 -> 128799 bytes, libcurl.a: unchanged
- macos llvm MultiSSL:
curl: 410056 -> 405720, libcurl.dylib: 1350336 -> 1348480 bytes
- mingw schannel c-ares U:
curl: 1588736 -> 1507328, libcurl-d.a: 3322040 -> 3884746 bytes
bld: 34 -> 35MB
- GHA: enable in MSVC and Apple jobs to reduce disk footprint, with no
obvious downside. Size changes:
- AppVeyor CI VS2019:
curl: 2339840 -> 1295872, libcurl-d.dll: 3155968 -> 1900544 bytes
bld: 161 -> 97MB
- AppVeyor CI VS2022 clang-cl:
curl: 2933248 -> 2332160, libcurl-d.lib: 4762688 -> 5511330 bytes
bld: 133 -> 121MB
- AppVeyor CI VS2022 HTTP-only:
curl: 3514368 -> 2177024, libcurl-d.lib: 2538420 -> 3151740 bytes
bld: 137 -> 83MB
- GHA intel:
curl: 2629120 -> 2023424, libcurl-d.lib: 4366652 -> 5350670 bytes
bld: 86 -> 69MB
- GHA arm64:
curl: 2832896 -> 2063872, libcurl-d.lib: 4690616 -> 5597250 bytes
bld: 82 -> 66MB
Refs:
https://maskray.me/blog/2021-02-28-linker-garbage-collectionhttps://web.archive.org/web/20110811230637/msdn.microsoft.com/en-us/library/bxwfs976.aspx (VS2010)
https://learn.microsoft.com/cpp/build/reference/opt-optimizationshttps://learn.microsoft.com/cpp/build/reference/gy-enable-function-level-linkingCloses#20357
Unstripped size hides effective binary sizes due to the added debug
information. E.g. `--gc-sections` may inflate unstripped binaries, while
their unstripped size decreases. To see if binary size optimization
options work, it's more useful to observe unstripped size.
Ref: #20357
Follow-up to 4cf43508e8#20355Closes#20359
