Re: [PATCH] mm/gfp: Add kernel-doc for gfp_t

[Nick Desaulniers <ndesaulniers@google.com>]

On Fri, Feb 19, 2021 at 12:55 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Feb 19, 2021 at 12:55:09PM -0700, Nathan Chancellor wrote:
> > On Mon, Feb 15, 2021 at 08:49:09PM +0000, Matthew Wilcox (Oracle) wrote:
> > > The generated html will link to the definition of the gfp_t automatically
> > > once we define it.  Move the one-paragraph overview of GFP flags from the
> > > documentation directory into gfp.h and pull gfp.h into the documentation.
> > >
> > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> >
> > This patch causes a clang warning in basically every file on linux-next
> > now:
> >
> > include/linux/gfp.h:20:32: warning: redefinition of typedef 'gfp_t' is a C11 feature [-Wtypedef-redefinition]
>
> Seems like it's also a gnu89 feature.

I'm not sure a lack of a warning is an intentional feature, and would
bet that behavior is not documented.

That said, I'm fine disabling this warning; there's a separate error
for redefining a typedef to a different underlying type.  That's
what's useful IMO, this one really is not.

This warning doesn't really provide any value to us in the kernel; I
would guess the intent was to be helpful to code expected to be
portable across different -std=*, but that's not the case for the
Linux kernel.  (It's also trivial to change this in Clang, but we'd
have to disable this warning for older supported of clang anyways).

diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index cee107096947..63529a43e797 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -2381,7 +2381,7 @@ void Sema::MergeTypedefNameDecl(Scope *S,
TypedefNameDecl *New,
   }

   // Modules always permit redefinition of typedefs, as does C11.
-  if (getLangOpts().Modules || getLangOpts().C11)
+  if (getLangOpts().Modules || getLangOpts().C11 || getLangOpts().GNUMode)
     return;

   // If we have a redefinition of a typedef in C, emit a warning.  This warning
-- 
Thanks,
~Nick Desaulniers