GeezerVison is showing github.com — clang-cl issues many warnings when building on Windows · Issue #131296 · python/cpython
clang-cl issues many warnings when building on Windows #131296DescriptionSee 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
|
<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
Activitypicnixz commented on Mar 15, 2025 Let's not backport those because I suspect it will sometimes be hard (hence the "feature") Reacted by Gregory P. Smith and Chris Eibl chris-eibl commented on Mar 15, 2025 Oh sure, no backport - I'd consider this a (minor) feature, anyway. Are warnings generally treated as bug issues here? gpshead commented on Mar 15, 2025 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 commented on Mar 15, 2025 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 commented on Mar 15, 2025 Ups, did you close the issue on purpose? Still a lot of warnings to go ... I am not that fast in creating the PRs :) chris-eibl commented on Mar 15, 2025 I've created three more PRs. Still more than 40 warnings to go ... chris-eibl commented on Aug 2, 2025 Having #131832 merged (thanks @zooba, not only for this one, but also for all the many others you've merged), we are now warning free in case of clang-cl on Windows with the currently used warning level and ignores
<AdditionalOptions>-Wno-pointer-sign -Wno-incompatible-pointer-types-discards-qualifiers -Wno-unused-function %(AdditionalOptions)</AdditionalOptions>
as we can e.g. see in the latest Windows tail calling CI build; https://github.com/python/cpython/actions/runs/16678905900/job/47212440421
We can either stop here and close this issue or continue (quoting my initial post)
Ideally, I'd like to end up with the same warning configuration as used on Linux.
if there is interest in it.
If so, please let me know and also whether this should be done in a follow-up issue. vstinner commented on Aug 4, 2025 I suggest closing this issue, and maybe open a new one if more warnings are found. chris-eibl commented on Aug 4, 2025 Sure, if we'd like to stick with the current warning settings, I'd vote for closing this issue (and create a new one if new warnings arise).
The question is, whether there is appetite by some core devs to go with stricter warning settings - like used on Linux. Using something like set via CONFIGURE_CFLAGS_NODIST for clang on Linux would produce a lot of new warnings with clang-cl on Windows.
Seems this should be done in a new issue - or not at all, if not worth to do ... zooba commented on Aug 4, 2025 Definitely a new issue.
It's worth seeing what issues are created - some are likely to be worth fixing (because they represent real bugs), even if we ultimately decide not to change the warning level. If you're able to write a commit message other than "fixes a warning" then it's probably worth fixing, but if the best reason for making the change is to suppress a compiler message then I think we're okay to leave them at this point.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|