On 12/27/22 11:15 AM, Dimitry Andric wrote:
On 27 Dec 2022, at 18:40, John Baldwin <j...@freebsd.org> wrote:
On 12/25/22 3:59 AM, Dimitry Andric wrote:
The branch main has been updated by dim:
URL:
https://cgit.FreeBSD.org/src/commit/?id=526f57bf85a2b9b113c55ded47b932abc8567bc5
commit 526f57bf85a2b9b113c55ded47b932abc8567bc5
Author: Dimitry Andric <d...@freebsd.org>
AuthorDate: 2022-07-25 10:29:58 +0000
Commit: Dimitry Andric <d...@freebsd.org>
CommitDate: 2022-12-25 11:58:22 +0000
Update CWARNFLAGS in bsd.sys.mk and CWARNEXTRA in kern.mk for clang 15.
MFC after: 3 days
---
share/mk/bsd.sys.mk | 17 +++++++++++++++--
sys/conf/kern.mk | 4 ++++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/share/mk/bsd.sys.mk b/share/mk/bsd.sys.mk
index a220c9d173ed..43359fed29c7 100644
--- a/share/mk/bsd.sys.mk
+++ b/share/mk/bsd.sys.mk
@@ -86,6 +94,11 @@ CWARNFLAGS.clang+= -Wno-unused-const-variable
.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} >= 130000
CWARNFLAGS.clang+= -Wno-error=unused-but-set-variable
.endif
+.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} >= 150000
+CWARNFLAGS.clang+= -Wno-error=array-parameter
I've fixed all these that GCC 12 finds. Do we really need to disable it for
clang
now after I've pushed those recent fixes?
I didn't notice, but it's likely because I had the above in the
llvm-15-update branch for months now. I found some old build logs from
the beginning of December, and they still contained ~20 of these
warnings. But if they're all fixed now then sure, lets's remove the
-Wno-error= again.
At least for amd64 they are clean for GCC (granted, sometimes GCC and
clang find different sets of warnings for these, and I haven't gotten
non-amd64 building with GCC 12 yet). If this is down to a small number
on recent main I think it's worth fixing the remaining ones and enabling
it.
+CWARNFLAGS.clang+= -Wno-error=deprecated-non-prototype
I'm curious how many places are broken by this and how much it would be to fix?
This is just adding '(void)' in place of '()', yes?
5859 instances, as of the last count. I committed a bunch of these, and
then got some negative feedback about it, so I decided to simply make
the warning non-fatal. Somebody else can go over these one by one and
fix them as drive-by commits. Indeed the fix is just replacing () in
declarations and definitions of C functions with (void).
Ok, that seems like a lot, so squashing it for now is prudent.
In general if folks are looking for simple but boring tasks, fixing the
real warnings for some of the warnings we currently squash so we can
enable them again would be nice.
--
John Baldwin
