| Message ID | 20230612093537.693926033@infradead.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | b5ec6fd286dfa466f64cb0e56ed768092d0342ae |
| Headers | show |
| Series | Scope-based Resource Management | expand |
On Mon, Jun 12, 2023 at 6:39 PM Peter Zijlstra <peterz@infradead.org> wrote: > > With the advent on scope-based resource management it comes really > tedious to abide by the contraints of -Wdeclaration-after-statement. Where is the context of Linus' suggested-by? I do not know where this came from. I suddenly got a huge v3 in my mailbox. I see an equivalent patch submitted last year: https://lore.kernel.org/lkml/Y1w031iI6Ld29IVT@p183/ Linus rejected it. Did he change his mind? > It will still be recommeneded to place declarations at the start of a > scope where possible, but it will no longer be enforced. If you remove the warning, we will not be able to detect code that opts out the recommendation for no good reason.
On Wed, Jun 14, 2023 at 03:13:03PM +0900, Masahiro Yamada wrote: > On Mon, Jun 12, 2023 at 6:39 PM Peter Zijlstra <peterz@infradead.org> wrote: > > > > With the advent on scope-based resource management it comes really > > tedious to abide by the contraints of -Wdeclaration-after-statement. > > Where is the context of Linus' suggested-by? > > I do not know where this came from. > I suddenly got a huge v3 in my mailbox. > > > I see an equivalent patch submitted last year: > https://lore.kernel.org/lkml/Y1w031iI6Ld29IVT@p183/ > > Linus rejected it. Did he change his mind? https://lkml.kernel.org/r/CAHk-%3Dwi-RyoUhbChiVaJZoZXheAwnJ7OO%3DGxe85BkPAd93TwDA%40mail.gmail.com I'll add it as a Link tag to the Changelog. > > > It will still be recommeneded to place declarations at the start of a > > scope where possible, but it will no longer be enforced. > > If you remove the warning, we will not be able to > detect code that opts out the recommendation > for no good reason. Yeah, so per that thread linked above I tried to play clever games with _Pragma() to get around this, but GCC hates on it (works fine with Clang though). Linus said to just give up and scrap the whole -Wdeclaration-after-statement thing. I suppose it'll be up to reviewers and perhaps checkpatch like things to 'enforce' the rules.
--- a/Makefile +++ b/Makefile @@ -447,8 +447,7 @@ HOSTRUSTC = rustc HOSTPKG_CONFIG = pkg-config KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \ - -O2 -fomit-frame-pointer -std=gnu11 \ - -Wdeclaration-after-statement + -O2 -fomit-frame-pointer -std=gnu11 KBUILD_USERCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(USERCFLAGS) KBUILD_USERLDFLAGS := $(USERLDFLAGS) @@ -1012,9 +1011,6 @@ endif # arch Makefile may override CC so keep this after arch Makefile is included NOSTDINC_FLAGS += -nostdinc -# warn about C99 declaration after statement -KBUILD_CFLAGS += -Wdeclaration-after-statement - # Variable Length Arrays (VLAs) should not be used anywhere in the kernel KBUILD_CFLAGS += -Wvla --- a/arch/arm64/kernel/vdso32/Makefile +++ b/arch/arm64/kernel/vdso32/Makefile @@ -65,11 +65,9 @@ VDSO_CFLAGS += -Wall -Wundef -Wstrict-pr -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ -Wno-format-security \ - -Wdeclaration-after-statement \ -std=gnu11 VDSO_CFLAGS += -O2 # Some useful compiler-dependent flags from top-level Makefile -VDSO_CFLAGS += $(call cc32-option,-Wdeclaration-after-statement,) VDSO_CFLAGS += $(call cc32-option,-Wno-pointer-sign) VDSO_CFLAGS += -fno-strict-overflow VDSO_CFLAGS += $(call cc32-option,-Werror=strict-prototypes)
With the advent on scope-based resource management it comes really tedious to abide by the contraints of -Wdeclaration-after-statement. It will still be recommeneded to place declarations at the start of a scope where possible, but it will no longer be enforced. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> --- Makefile | 6 +----- arch/arm64/kernel/vdso32/Makefile | 2 -- 2 files changed, 1 insertion(+), 7 deletions(-)