Correctly diagnose prototype redeclaration errors in C

[aaron.ballman]

Summary

We did not implement C99 6.7.5.3p15 fully in that we missed the rule for compatible function types where a prior declaration has a prototype and a subsequent definition (not just declaration) has an empty identifier list or an identifier list with a mismatch in parameter arity. This addresses that situation by issuing an error on code like:

void f(int);
void f() {} // type conflicts with previous declaration

(Note: we already diagnose the other type conflict situations appropriately, this was the only situation we hadn't covered that I could find.)

[erichkeane]

This LGTM, please give a day or so for others to take a look.

clang/test/Sema/predefined-function.c

27

Oh my!

[jyknight]

clang/test/Sema/warn-deprecated-non-prototype.c

64–70

Reword to indicate that the second diagnostic is now an error.

[aaron.ballman]

Thank you for the reviews, I've landed in 385e7df33046d7292612ee1e3ac00a59d8bc0441.

clang/test/Sema/warn-deprecated-non-prototype.c

64–70

Good catch!

[uweigand]

It looks like this caused the LNT build bot to fail (at least on s390x), because one of the test cases now triggers this error:
https://lab.llvm.org/buildbot/#/builders/45/builds/6787

/usr/bin/make -f SingleSource/Regression/C/gcc-c-torture/execute/ieee/CMakeFiles/GCC-C-execute-ieee-compare-fp-4.dir/build.make SingleSource/Regression/C/gcc-c-torture/execute/ieee/CMakeFiles/GCC-C-execute-ieee-compare-fp-4.dir/build
/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/test-suite/SingleSource/Regression/C/gcc-c-torture/execute/ieee/20030331-1.c:6:1: error: conflicting types for 'rintf'
rintf ()
^
/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/test-suite/SingleSource/Regression/C/gcc-c-torture/execute/ieee/20030331-1.c:6:1: note: previous implicit declaration is here
make[2]: Entering directory '/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/sandbox/build'
/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/test-suite/SingleSource/Regression/C/gcc-c-torture/execute/ieee/20030331-1.c:29:14: error: too few arguments to function call, expected 1, have 0
  if (rintf () != -2.0)
      ~~~~~  ^
2 errors generated.

I guess the error is valid, but should either be disabled for this LNT test, or else the test fixed.

[aaron.ballman]

In D123627#3451269, @uweigand wrote:

It looks like this caused the LNT build bot to fail (at least on s390x), because one of the test cases now triggers this error:
https://lab.llvm.org/buildbot/#/builders/45/builds/6787

/usr/bin/make -f SingleSource/Regression/C/gcc-c-torture/execute/ieee/CMakeFiles/GCC-C-execute-ieee-compare-fp-4.dir/build.make SingleSource/Regression/C/gcc-c-torture/execute/ieee/CMakeFiles/GCC-C-execute-ieee-compare-fp-4.dir/build
/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/test-suite/SingleSource/Regression/C/gcc-c-torture/execute/ieee/20030331-1.c:6:1: error: conflicting types for 'rintf'
rintf ()
^
/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/test-suite/SingleSource/Regression/C/gcc-c-torture/execute/ieee/20030331-1.c:6:1: note: previous implicit declaration is here
make[2]: Entering directory '/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/sandbox/build'
/home/uweigand/sandbox/buildbot/clang-s390x-linux-lnt/test/test-suite/SingleSource/Regression/C/gcc-c-torture/execute/ieee/20030331-1.c:29:14: error: too few arguments to function call, expected 1, have 0
  if (rintf () != -2.0)
      ~~~~~  ^
2 errors generated.

I guess the error is valid, but should either be disabled for this LNT test, or else the test fixed.

Thank you for letting me know -- I've speculatively fixed the issue in 726901d06aab2f92d684d28507711308368c29d6

[efriedma]

In D123627#3451373, @aaron.ballman wrote:

Thank you for letting me know -- I've speculatively fixed the issue in 726901d06aab2f92d684d28507711308368c29d6

Can you also look into improving the error message? Just saying "conflicting types for 'rintf'", with a note saying the previous declaration is at the exact same location, is going to confuse anyone who writes float rintf(){}.

[aaron.ballman]

In D123627#3452424, @efriedma wrote:

In D123627#3451373, @aaron.ballman wrote:

Thank you for letting me know -- I've speculatively fixed the issue in 726901d06aab2f92d684d28507711308368c29d6

Can you also look into improving the error message? Just saying "conflicting types for 'rintf'", with a note saying the previous declaration is at the exact same location, is going to confuse anyone who writes float rintf(){}.

FWIW, I agree with you that the diagnostic message is less than helpful. But it's consistent with the message we used in all of the other declaration situations (https://godbolt.org/z/e6hcc4Y3Y) which is why I didn't add a better diagnostic message.

The reason you get the weird behavior with the note pointing to the same line as the declaration is because rintf() is a predefined builtin: https://godbolt.org/z/j3W759M7a (note the same lovely diagnostic note behavior).

So yes, it'd be nice to get better diagnostic behavior in this area, but it's orthogonal to the changes here.

[efriedma]

The reason you get the weird behavior with the note pointing to the same line as the declaration is because rintf() is a predefined builtin: https://godbolt.org/z/j3W759M7a (note the same lovely diagnostic note behavior).

It points at the same location, but at least it says "'rintf' is a builtin" (diag::note_previous_builtin_declaration). The new codepath specifically skips the code which emits that note.

[aaron.ballman]

In D123627#3452491, @efriedma wrote:

The reason you get the weird behavior with the note pointing to the same line as the declaration is because rintf() is a predefined builtin: https://godbolt.org/z/j3W759M7a (note the same lovely diagnostic note behavior).

It points at the same location, but at least it says "'rintf' is a builtin" (diag::note_previous_builtin_declaration). The new codepath specifically skips the code which emits that note.

Oh, good catch! It looks like getNoteDiagForInvalidRedeclaration() doesn't consider using that particular note and it probably should, I'll look into that. Thanks!

[uweigand]

In D123627#3451373, @aaron.ballman wrote:

Thank you for letting me know -- I've speculatively fixed the issue in 726901d06aab2f92d684d28507711308368c29d6

Yes, the build bot is now green again. Thanks!

[aaron.ballman]

In D123627#3452572, @uweigand wrote:

In D123627#3451373, @aaron.ballman wrote:

Thank you for letting me know -- I've speculatively fixed the issue in 726901d06aab2f92d684d28507711308368c29d6

Yes, the build bot is now green again. Thanks!

Excellent, thank you again for bringing the issue to my attention.

[aaron.ballman]

In D123627#3452491, @efriedma wrote:

The reason you get the weird behavior with the note pointing to the same line as the declaration is because rintf() is a predefined builtin: https://godbolt.org/z/j3W759M7a (note the same lovely diagnostic note behavior).

It points at the same location, but at least it says "'rintf' is a builtin" (diag::note_previous_builtin_declaration). The new codepath specifically skips the code which emits that note.

This situation should now be improved in c7d4a05228090cb6b1b7f6e5d300f197897ac756.

[efriedma]

If the declaration we're redeclaring is a builtin, should the diagnostic be in the "-Wincompatible-library-redeclaration" warning group? With this patch, we treat redefinitions of builtins without a prototype differently from redefinitions with a prototype, for example:

void acos() {} // error
void acos(void) {} // warning

Just ran into some code in Android which is using the first form.

[aaron.ballman]

In D123627#3707635, @efriedma wrote:

If the declaration we're redeclaring is a builtin, should the diagnostic be in the "-Wincompatible-library-redeclaration" warning group? With this patch, we treat redefinitions of builtins without a prototype differently from redefinitions with a prototype, for example:

void acos() {} // error
void acos(void) {} // warning

Just ran into some code in Android which is using the first form.

Er, I keep going back and forth on it. My initial inclination is that this is closing a hole where we would incorrectly decide that these function signatures are compatible enough to merge together when that's not the case, so an error is appropriate. But the same can be said for redeclaring a builtin with an incorrect prototype rather than declaring it without any prototype. Given that these builtins are declared for the user automagically, I think I come down on this being a case we'd rather warn instead of err. It'd be weird to allow the user to define void printf(void) {} but not void printf(); (except in C2x mode).

If we make a change here, I think it'd be good to get it done for Clang 15. I'm not certain I've got the bandwidth to make this change in that timeframe though (I can hopefully start on this sometime this week, but I have prior commitments with deadlines that take priority).

[aaron.ballman]

In D123627#3707789, @aaron.ballman wrote:

In D123627#3707635, @efriedma wrote:

If the declaration we're redeclaring is a builtin, should the diagnostic be in the "-Wincompatible-library-redeclaration" warning group? With this patch, we treat redefinitions of builtins without a prototype differently from redefinitions with a prototype, for example:

void acos() {} // error
void acos(void) {} // warning

Just ran into some code in Android which is using the first form.

Er, I keep going back and forth on it. My initial inclination is that this is closing a hole where we would incorrectly decide that these function signatures are compatible enough to merge together when that's not the case, so an error is appropriate. But the same can be said for redeclaring a builtin with an incorrect prototype rather than declaring it without any prototype. Given that these builtins are declared for the user automagically, I think I come down on this being a case we'd rather warn instead of err. It'd be weird to allow the user to define void printf(void) {} but not void printf(); (except in C2x mode).

If we make a change here, I think it'd be good to get it done for Clang 15. I'm not certain I've got the bandwidth to make this change in that timeframe though (I can hopefully start on this sometime this week, but I have prior commitments with deadlines that take priority).

I filed https://reviews.llvm.org/D131499 for this.

clang/docs/ReleaseNotes.rst

- Modified the behavior of ``-Wstrict-prototypes`` and added a new, related
   diagnostic ``-Wdeprecated-non-prototype``. The strict prototypes warning will
   now only diagnose deprecated declarations and definitions of functions
   without a prototype where the behavior in C2x will remain correct. This
   diagnostic remains off by default but is now enabled via ``-pedantic`` due to
   it being a deprecation warning. ``-Wdeprecated-non-prototype`` will diagnose
   cases where the deprecated declarations or definitions of a function without
   a prototype will change behavior in C2x. This diagnostic is grouped under the
   ``-Wstrict-prototypes`` warning group, but is enabled by default.
+- Clang now appropriately issues an error in C when a definition of a function
+  without a prototype and with no arguments is an invalid redeclaration of a
+  function with a prototype. e.g., ``void f(int); void f() {}`` is now properly
+  diagnosed.
 
 Non-comprehensive list of changes in this release
 -------------------------------------------------
 - Improve __builtin_dump_struct:
   - Support bitfields in struct and union.
   - Improve the dump format, dump both bitwidth(if its a bitfield) and field value.
   - Remove anonymous tag locations.
   - Beautify dump format, add indent for nested struct and struct members.

clang/include/clang/Sema/Sema.h

   void DiagnoseHiddenVirtualMethods(CXXMethodDecl *MD);
   void FindHiddenVirtualMethods(CXXMethodDecl *MD,
                           SmallVectorImpl<CXXMethodDecl*> &OverloadedMethods);
   void NoteHiddenVirtualMethods(CXXMethodDecl *MD,
                           SmallVectorImpl<CXXMethodDecl*> &OverloadedMethods);
   // Returns true if the function declaration is a redeclaration
   bool CheckFunctionDeclaration(Scope *S,
                                 FunctionDecl *NewFD, LookupResult &Previous,
-                                bool IsMemberSpecialization);
+                                bool IsMemberSpecialization, bool DeclIsDefn);
   bool shouldLinkDependentDeclWithPrevious(Decl *D, Decl *OldDecl);
   bool canFullyTypeCheckRedeclaration(ValueDecl *NewD, ValueDecl *OldD,
                                       QualType NewT, QualType OldT);
   void CheckMain(FunctionDecl *FD, const DeclSpec &D);
   void CheckMSVCRTEntryPoint(FunctionDecl *FD);
   Attr *getImplicitCodeSegOrSectionAttrForFunction(const FunctionDecl *FD,
                                                    bool IsDefinition);
   void CheckFunctionOrTemplateParamDeclarator(Scope *S, Declarator &D);

                                               const AttributeCommonInfo &AL,
                                               int X, int Y, int Z);
 
   void mergeDeclAttributes(NamedDecl *New, Decl *Old,
                            AvailabilityMergeKind AMK = AMK_Redeclaration);
   void MergeTypedefNameDecl(Scope *S, TypedefNameDecl *New,
                             LookupResult &OldDecls);
   bool MergeFunctionDecl(FunctionDecl *New, NamedDecl *&Old, Scope *S,
-                         bool MergeTypeWithOld);
+                         bool MergeTypeWithOld, bool NewDeclIsDefn);
   bool MergeCompatibleFunctionDecls(FunctionDecl *New, FunctionDecl *Old,
                                     Scope *S, bool MergeTypeWithOld);
   void mergeObjCMethodDecls(ObjCMethodDecl *New, ObjCMethodDecl *Old);
   void MergeVarDecl(VarDecl *New, LookupResult &Previous);
   void MergeVarDeclTypes(VarDecl *New, VarDecl *Old, bool MergeTypeWithOld);
   void MergeVarDeclExceptionSpecs(VarDecl *New, VarDecl *Old);
   bool checkVarDeclRedefinition(VarDecl *OldDefn, VarDecl *NewDefn);
   void notePreviousDefinition(const NamedDecl *Old, SourceLocation New);

clang/lib/Sema/SemaDecl.cpp

 /// merging decls or emitting diagnostics as appropriate.
 ///
 /// In C++, New and Old must be declarations that are not
 /// overloaded. Use IsOverload to determine whether New and Old are
 /// overloaded, and to select the Old declaration that New should be
 /// merged with.
 ///
 /// Returns true if there was an error, false otherwise.
-bool Sema::MergeFunctionDecl(FunctionDecl *New, NamedDecl *&OldD,
-                             Scope *S, bool MergeTypeWithOld) {
+bool Sema::MergeFunctionDecl(FunctionDecl *New, NamedDecl *&OldD, Scope *S,
+                             bool MergeTypeWithOld, bool NewDeclIsDefn) {
   // Verify the old decl was also a function.
   FunctionDecl *Old = OldD->getAsFunction();
   if (!Old) {
     if (UsingShadowDecl *Shadow = dyn_cast<UsingShadowDecl>(OldD)) {
       if (New->getFriendObjectKind()) {
         Diag(New->getLocation(), diag::err_using_decl_friend);
         Diag(Shadow->getTargetDecl()->getLocation(),
              diag::note_using_decl_target);

       return false;
 
     // Fall through for conflicting redeclarations and redefinitions.
   }
 
   // C: Function types need to be compatible, not identical. This handles
   // duplicate function decls like "void f(int); void f(enum X);" properly.
   if (!getLangOpts().CPlusPlus) {
+    // C99 6.7.5.3p15: ...If one type has a parameter type list and the other
+    // type is specified by a function definition that contains a (possibly
+    // empty) identifier list, both shall agree in the number of parameters
+    // and the type of each parameter shall be compatible with the type that
+    // results from the application of default argument promotions to the
+    // type of the corresponding identifier. ...
+    // This cannot be handled by ASTContext::typesAreCompatible() because that
+    // doesn't know whether the function type is for a definition or not when
+    // eventually calling ASTContext::mergeFunctionTypes(). The only situation
+    // we need to cover here is that the number of arguments agree as the
+    // default argument promotion rules were already checked by
+    // ASTContext::typesAreCompatible().
+    if (Old->hasPrototype() && !New->hasWrittenPrototype() && NewDeclIsDefn &&
+        Old->getNumParams() != New->getNumParams()) {
+      Diag(New->getLocation(), diag::err_conflicting_types) << New;
+      Diag(Old->getLocation(), PrevDiag) << Old << Old->getType();
+      return true;
+    }
+
     // If we are merging two functions where only one of them has a prototype,
     // we may have enough information to decide to issue a diagnostic that the
     // function without a protoype will change behavior in C2x. This handles
     // cases like:
     //   void i(); void i(int j);
     //   void i(int j); void i();
     //   void i(); void i(int j) {}
     // See ActOnFinishFunctionBody() for other cases of the behavior change

     if (!NewFD->isInvalidDecl() && NewFD->isMain())
       CheckMain(NewFD, D.getDeclSpec());
 
     if (!NewFD->isInvalidDecl() && NewFD->isMSVCRTEntryPoint())
       CheckMSVCRTEntryPoint(NewFD);
 
     if (!NewFD->isInvalidDecl())
       D.setRedeclaration(CheckFunctionDeclaration(S, NewFD, Previous,
-                                                  isMemberSpecialization));
+                                                  isMemberSpecialization,
+                                                  D.isFunctionDefinition()));
     else if (!Previous.empty())
       // Recover gracefully from an invalid redeclaration.
       D.setRedeclaration(true);
     assert((NewFD->isInvalidDecl() || !D.isRedeclaration() ||
             Previous.getResultKind() != LookupResult::FoundOverloaded) &&
            "previous declaration set still overloaded");
 
     // Diagnose no-prototype function declarations with calling conventions that

       if (!NewFD->isInvalidDecl() && NewFD->isMain())
         CheckMain(NewFD, D.getDeclSpec());
 
       if (!NewFD->isInvalidDecl() && NewFD->isMSVCRTEntryPoint())
         CheckMSVCRTEntryPoint(NewFD);
 
       if (!NewFD->isInvalidDecl())
         D.setRedeclaration(CheckFunctionDeclaration(S, NewFD, Previous,
-                                                    isMemberSpecialization));
+                                                    isMemberSpecialization,
+                                                    D.isFunctionDefinition()));
       else if (!Previous.empty())
         // Recover gracefully from an invalid redeclaration.
         D.setRedeclaration(true);
     }
 
     assert((NewFD->isInvalidDecl() || !D.isRedeclaration() ||
             Previous.getResultKind() != LookupResult::FoundOverloaded) &&
            "previous declaration set still overloaded");

 /// a member specialization (that replaces any definition provided by the
 /// previous declaration).
 ///
 /// This sets NewFD->isInvalidDecl() to true if there was an error.
 ///
 /// \returns true if the function declaration is a redeclaration.
 bool Sema::CheckFunctionDeclaration(Scope *S, FunctionDecl *NewFD,
                                     LookupResult &Previous,
-                                    bool IsMemberSpecialization) {
+                                    bool IsMemberSpecialization,
+                                    bool DeclIsDefn) {
   assert(!NewFD->getReturnType()->isVariablyModifiedType() &&
          "Variably modified return types are not handled here");
 
   // Determine whether the type of this function should be merged with
   // a previous visible declaration. This never happens for functions in C++,
   // and always happens in C if the previous declaration was visible.
   bool MergeTypeWithPrevious = !getLangOpts().CPlusPlus &&
                                !Previous.isShadowed();

           << FixItHint::CreateInsertion(AddConstLoc, " const");
       }
     }
   }
 
   if (Redeclaration) {
     // NewFD and OldDecl represent declarations that need to be
     // merged.
-    if (MergeFunctionDecl(NewFD, OldDecl, S, MergeTypeWithPrevious)) {
+    if (MergeFunctionDecl(NewFD, OldDecl, S, MergeTypeWithPrevious,
+                          DeclIsDefn)) {
       NewFD->setInvalidDecl();
       return Redeclaration;
     }
 
     Previous.clear();
     Previous.addDecl(OldDecl);
 
     if (FunctionTemplateDecl *OldTemplateDecl =

clang/lib/Sema/SemaDeclCXX.cpp

   LookupResult R(*this, Name, SourceLocation(), LookupOrdinaryName,
                  ForExternalRedeclaration);
   for (auto *D : FD->getParent()->lookup(Name))
     if (auto *Acceptable = R.getAcceptableDecl(D))
       R.addDecl(Acceptable);
   R.resolveKind();
   R.suppressDiagnostics();
 
-  CheckFunctionDeclaration(S, FD, R, /*IsMemberSpecialization*/false);
+  CheckFunctionDeclaration(S, FD, R, /*IsMemberSpecialization*/ false,
+                           FD->isThisDeclarationADefinition());
 }
 
 void Sema::setupImplicitSpecialMemberType(CXXMethodDecl *SpecialMem,
                                           QualType ResultTy,
                                           ArrayRef<QualType> Args) {
   // Build an exception specification pointing back at this constructor.
   FunctionProtoType::ExtProtoInfo EPI = getImplicitMethodEPI(*this, SpecialMem);
 

clang/lib/Sema/SemaTemplateInstantiateDecl.cpp

     // effect this has is to remove declarations found in inline namespaces
     // for friend declarations with unqualified names.
     SemaRef.FilterLookupForScope(Previous, DC, /*Scope*/ nullptr,
                                  /*ConsiderLinkage*/ true,
                                  QualifierLoc.hasQualifier());
   }
 
   SemaRef.CheckFunctionDeclaration(/*Scope*/ nullptr, Function, Previous,
-                                   IsExplicitSpecialization);
+                                   IsExplicitSpecialization,
+                                   Function->isThisDeclarationADefinition());
 
   // Check the template parameter list against the previous declaration. The
   // goal here is to pick up default arguments added since the friend was
   // declared; we know the template parameter lists match, since otherwise
   // we would not have picked this template as the previous declaration.
   if (isFriend && TemplateParams && FunctionTemplate->getPreviousDecl()) {
     SemaRef.CheckTemplateParameterList(
         TemplateParams,

     // (class or enum). In this case, the new declaration will hide the
     // tag type. Note that this does does not apply if we're declaring a
     // typedef (C++ [dcl.typedef]p4).
     if (Previous.isSingleTagDecl())
       Previous.clear();
   }
 
   SemaRef.CheckFunctionDeclaration(nullptr, Method, Previous,
-                                   IsExplicitSpecialization);
+                                   IsExplicitSpecialization,
+                                   Method->isThisDeclarationADefinition());
 
   if (D->isPure())
     SemaRef.CheckPureMethod(Method, SourceRange());
 
   // Propagate access.  For a non-friend declaration, the access is
   // whatever we're propagating from.  For a friend, it should be the
   // previous declaration we just found.
   if (isFriend && Method->getPreviousDecl())

clang/test/CodeGen/functions.c

 }
 
 // rdar://6110827
 typedef void T(void);
 void test3(T f) {
   f();
 }
 
-int a(int);
-int a() {return 1;}
-
 void f0(void) {}
 // CHECK-LABEL: define{{.*}} void @f0()
 
 void f1();
 void f2(void) {
 // CHECK: call void @f1()
   f1(1, 2, 3);
 }

clang/test/Sema/predefined-function.c

int foo() {
   return 0;
 }
 
 int bar();
 int bar(int i) // expected-note {{previous definition is here}}
 {
   return 0;
 }
-int bar() // expected-error {{redefinition of 'bar'}} 
+int bar() // expected-error {{conflicting types for 'bar'}}
 {
   return 0;
 }
 
-int foobar(int); // note {{previous declaration is here}}
-int foobar() // error {{conflicting types for 'foobar'}}
+int foobar(int); // expected-note {{previous declaration is here}}
+int foobar() // expected-error {{conflicting types for 'foobar'}}
 {
   return 0;
 }
 
 int wibble(); // expected-note {{previous declaration is here}}
 float wibble() // expected-error {{conflicting types for 'wibble'}}
 {
   return 0.0f;
 }

clang/test/Sema/prototype-redecls.c

+// RUN: %clang_cc1 -fsyntax-only -Wno-strict-prototypes -verify %s
+
+void blapp(int); // expected-note {{previous}}
+void blapp() { } // expected-error {{conflicting types for 'blapp'}}
+
+void yarp(int, ...); // expected-note {{previous}}
+void yarp();         // expected-error {{conflicting types for 'yarp'}}
+
+void blarg(int, ...); // expected-note {{previous}}
+void blarg() {}       // expected-error {{conflicting types for 'blarg'}}
+
+void blerp(short);      // expected-note {{previous}}
+void blerp(x) int x; {} // expected-error {{conflicting types for 'blerp'}}
+
+void glerp(int);
+void glerp(x) short x; {} // Okay, promoted type is fine
+
+// All these cases are okay
+void derp(int);
+void derp(x) int x; {}
+
+void garp(int);
+void garp();
+void garp(x) int x; {}

clang/test/Sema/warn-deprecated-non-prototype.c

 // Just because the prototype is variadic doesn't mean we shouldn't warn on the
 // K&R C function definition; this still changes behavior in C2x.
 void test(char*,...);
 void test(fmt)        // both-warning {{a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x}}
         char*fmt;
 {
 }
 
 // FIXME: we get two diagnostics here when running in pedantic mode. The first
 // comes when forming the function type for the definition, and the second
 // comes from merging the function declarations together. The second is the
 // point at which we know the behavior has changed (because we can see the
 // previous declaration at that point), but we've already issued the type
 // warning by that point. It's not ideal to be this chatty, but this situation
 // should be pretty rare.
-void blapp(int);
-void blapp() { } // both-warning {{a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x}} \
+void blapp(int); // both-note {{previous declaration is here}}
+void blapp() { } // both-error {{conflicting types for 'blapp'}} \
                  // strict-warning {{a function declaration without a prototype is deprecated in all versions of C}}