clang-cl issues many warnings when building on Windows

[chris-eibl]

See e.g. https://github.com/python/cpython/actions/runs/13681800146/job/38255779088.

I went through roughly 100 warnings to find this one #131020.

Others are mostly benign, yet I'd like to reduce them.

Since many of the warnings stem from pythoncore, we see them twice, because the _freeze_module compiles a lot of those *.c files, too - and in case of PGO we see them a third time in the PGUpdate phase.

E.g. a bunch of warnings will disappear after the next sync with hacl-star upstream, since @msprotz thankfully already merged hacl-star/hacl-star#1028.

I think it is best to do them in small PRs per *.c file.

Ideally, I'd like to end up with the same warning configuration as used on Linux. When I configure for clang in WSL, I get

CONFIGURE_CFLAGS_NODIST= -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden

This would currently generate even more warnings, since we currently use

cpython/PCbuild/pyproject-clangcl.props

Line 41 in faa80fc

<AdditionalOptions>-Wno-deprecated-non-prototype -Wno-unused-label -Wno-pointer-sign -Wno-incompatible-pointer-types-discards-qualifiers -Wno-unused-function %(AdditionalOptions)</AdditionalOptions>

So maybe I should do this after a first round of cleaning?

Linked PRs

• GH-131296: fix clang-cl warning on Windows in pytime.c #131297
• GH-131296: fix clang-cl warnings on Windows in blake2module.c #131299
• GH-131296: fix clang-cl warnings on Windows in pyshellext.cpp #131300
• GH-131296: fix clang-cl warnings in fileutils.c #131301
• GH-131296: clang-cl: fix "unused variable flags" warning #131302
• GH-131296: clang-cl on Windows: fix unused warning "self" in fileio.c #131303
• GH-131296: fix clang-cl warnings in sysmodule.c #131304
• GH-131296: fix clang-cl warning in tracemalloc.c #131374
• gh-131296: fix clang-cl warning in tracemalloc.c #131514
• GH-131296: fix clang-cl warning on Windows in pegen.h #131584
• GH-131296: fix clang-cl warning on Windows in _wmimodule.cpp #131587
• GH-131296: fix clang-cl warning on Windows in thread_nt.h #131589
• GH-131296: fix clang-cl warning on Windows in overlapped.c #131590
• GH-131296: fix clang-cl warning on Windows in sre.c #131593
• GH-131296: fix clang-cl warning on Windows in getpath.c #131594
• GH-131296: fix clang-cl warning on Windows in semaphore.c #131595
• GH-131296: fix clang-cl warning on Windows in _winapi.c #131600
• GH-131296: fix clang-cl warning on Windows in longobject.c for 32bit builds #131604
• GH-131296: fix clang-cl warning on Windows in socketmodule.c #131821
• GH-131296: fix clang-cl warning on Windows in socketmodule.h #131832
• GH-131296: fix clang-cl warning on Windows in liblzma #131897
• GH-131296: move suppression of "unused label" warning for clang-cl on Windows #131900
• GH-131296: fix clang-cl parentheses warnings on Windows #131905
• GH-131296: fix clang-cl warnings on Windows in sqlite3 #131906
• gh-131296: Fix clang-cl warning on Windows in posixmodule.c #133142
• [3.14] GH-131296: Suppress clang-cl warnings in socketmodule.c (GH-131821) #146339
• [3.14] GH-131296: Fix clang-cl warning on Windows in socketmodule.h (GH-131832) #146340

[picnixz]

Let's not backport those because I suspect it will sometimes be hard (hence the "feature")

[chris-eibl]

Oh sure, no backport - I'd consider this a (minor) feature, anyway. Are warnings generally treated as bug issues here?

[gpshead]

thanks! all three of those should merge. actually looking at compiler warnings and minimizing them is a good thing...

we do have some CI tests that check for changes in number of warnings on other platforms, if we get clang-cl in CI, even non-blocking, we should add the same for it. ex the "Check compiler warnings" ones in .github/workflows/reusable-{macos,ubuntu}.yml.

I do consider uninvestigated warnings to be bugs. But when it isn't a https://peps.python.org/pep-0011/ tier platform arguing for it can be hard. I think clang-cl is close enough even if not on a tier yet as we obviously already care about clang warnings on other platforms that its value is demonstrable.

[chris-eibl]

Yupp. I fully agree. My main motivation is, that clang-cl "sees all the Windows code" for which MSVC with the currently selected warning level produces no warnings. Some are really easy to fix, and will no longer cover the "real" ones like #131020.

[chris-eibl]

Ups, did you close the issue on purpose? Still a lot of warnings to go ... I am not that fast in creating the PRs :)