[C2x] Disallow functions without prototypes/functions with identifier lists

[aaron.ballman]

Summary

WG14 has elected to remove support for K&R C functions in C2x. The feature was introduced into C89 already deprecated, so after this long of a deprecation period, the committee has made an empty parameter list mean the same thing in C as it means in C++: the function accepts no arguments exactly as if the function were written with (void) as the parameter list.

This patch implements WG14 N2841 No function declarators without prototypes (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm) and WG14 N2432 Remove support for function definitions with identifier lists (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf).

[erichkeane]

clang/lib/AST/ASTContext.cpp

11243

How tough would it be to change this to represent always as a C++-esque foo(...) prototype, just always?

clang/lib/Sema/SemaDecl.cpp

8821

This assert is quite strange, particularly with the string part of it only in the 'else' of the conditional? It seems you're trying to ensure that:
"if strictProtoTypes, assert hasProtoType"?

In that case, I'd likely suggest:

assert((HasProtoType || !SemeaRef.getLangOpts().StrictPrototypes) && "Strict prototypes are required");

clang/test/Parser/c2x-attributes.c

64

This is an unfortunate change in diagnostic quality.

[aaron.ballman]

clang/lib/AST/ASTContext.cpp

11243

C doesn't allow that (but we do if the user specifies the overloadable attribute), so it could be a bit tricky.

clang/lib/Sema/SemaDecl.cpp

8821

You decoded what I was going for, but I like your approach better. Thanks!

clang/test/Parser/c2x-attributes.c

64

Agreed, but thankfully this situation should be exceedingly rare (trying to put [[]] attributes after a function definition with an identifier list).

[aaron.ballman]

Updated based on review feedback

[erichkeane]

clang/lib/AST/ASTContext.cpp

11243

Hmm... I guess that is fair. Thinking further, we likely 'assume' that cannot be the case else where :/

clang/test/Parser/c2x-attributes.c

64

Ah! less concerned then.

[cor3ntin]

Thanks for working on this, Just a few comments

clang/lib/Basic/LangOptions.cpp

119

Stupid question, we probably don't want -fno-strict-prototype` to have an effect in C++. is there something to deal with that? I'm not familiar with the option system

clang/lib/Sema/SemaDecl.cpp

8821–8823

That would make more sense to me, not that it affects the logic

assert((SemaRef.getLangOpts().StrictPrototypes
               ? HasPrototype
               : true) && "Strict prototypes are required");

clang/lib/Sema/SemaType.cpp

5299

can you explain the Context.IntTy here ?

[aaron.ballman]

clang/lib/Basic/LangOptions.cpp

119

I don't currently expose a user-facing option for this yet. I was thinking about it, but wasn't certain if -Werror=deprecated-non-prototype was sufficient or not.

That said, if I did produce a user-facing option, I would not expose an -fno-strict-prototype option at all. Users can opt into strict prototypes, but they cannot opt out of them.

clang/lib/Sema/SemaType.cpp

5299

It's our default fallback type -- we use the same thing on line 5120 as an example. It shouldn't matter overly much as we tell the declarator that it has an invalid type.

[rsmith]

clang/include/clang/Basic/LangOptions.def

124

This makes me think we should have some declarative way of specifying dependencies between LANGOPTs. It's presumably sufficiently obvious to a library user that they shouldn't enable (eg) CPlusPlus20 unless they enable all the previous CPlusPlusXY modes and CPlusPlus, but I doubt it's obvious that enabling CPlusPlus requires also enabling StrictPrototypes.

In fact, after this change, I think a lot of existing library users of Clang that invent their own LangOptions will silently start getting this wrong. That's concerning. Maybe we should consider prototypes to be required if either StrictPrototypes or CPlusPlus is enabled?

clang/lib/Parse/ParseDecl.cpp

6664–6666

I don't follow this comment: functions without a prototype are not variadic (they're compatible with any *non-variadic* prototype), so OpenCL disallowing variadic functions seems irrelevant here.

clang/lib/Sema/SemaType.cpp

5273–5275

Same as before, OpenCL disallowing variadics doesn't seem relevant here.

clang/lib/StaticAnalyzer/Core/MemRegion.cpp

1034–1042

I find it really surprising that the "signature is present but is not a function type" case is reachable -- the static analyzer should only run on valid code, and in valid code I'd expect the signature of a block would always be a function type. Is that case actually reached in our test suite?

I worry that the "block has no explicit signature" case here is common, and that we're losing substantial coverage in that case. Per https://clang.llvm.org/docs/BlockLanguageSpec.html#block-literal-expressions, ^ { ... } is equivalent to ^ (void) { ... }, so it seems the original code here was just wrong and we should always have been creating a FunctionProtoType in this case.

[aaron.ballman]

clang/include/clang/Basic/LangOptions.def

124

This makes me think we should have some declarative way of specifying dependencies between LANGOPTs.

Tee hee: https://github.com/llvm/llvm-project/commit/be9371659380388a693ec99624e1f3d02f07047f

I was caught by the same issues that I ended up fixing in that commit -- I tried making StrictPrototypes dependent and was very surprised when it doesn't work. The issue was Invocation->getLangOpts()->resetNonModularOptions(); in compileModuleImpl() IIRC -- it would clear all of the language options (including ones like digraphs and wchar support).

In fact, after this change, I think a lot of existing library users of Clang that invent their own LangOptions will silently start getting this wrong. That's concerning. Maybe we should consider prototypes to be required if either StrictPrototypes or CPlusPlus is enabled?

@cor3ntin also shared this same concern -- my goal with this language option was:

• Make it easy to reenable functions without prototypes in C2x mode if we find some major breakage in the wild (hopefully we don't)
• Make it easy to add -fstrict-prototypes as a language flag to opt *into* strict prototypes (there would be no option to opt *out* of strict prototypes).
• Stop repeating CPlusPlus || C2x in a bunch of places and give it a named option.

So I'm not keen on adding StrictPrototypes || CPlusPlus everywhere -- C++ requires strict prototypes. However, the fears are still valid -- what if I found someplace nice to add an assert that StrictPrototypes cannot be false when CPlusPlus is true?

clang/lib/Parse/ParseDecl.cpp

6664–6666

Heh, this comment came from feedback I got from someone on IRC when I was asking what OpenCL actually supports. As best I found, OpenCL allows void f(); to mean void f(void); as in C++, but also allows void f(a, b) int a, b; {} (despite having no way to actually declare this function).

I'll take a pass at fixing up the comment to be more clear, thanks!

clang/lib/Sema/SemaType.cpp

5273–5275

Same here as above.

clang/lib/StaticAnalyzer/Core/MemRegion.cpp

1034–1042

I tried raising someone from the static analyzer team on IRC and failed, so this was my best guess.

Without this change, we get two assertions (when I enabled the asserts in getFunctionNoProtoType()): test/Analysis/blocks.m and test/Analysis/templates.cpp. So we definitely reach this spot. Given the FIXME comment above my changes, it looks like the analyzer folks knew they were doing something wrong here. With these changes, I get no test failures, so I'm not certain we're losing substantial coverage or not.

I think you might be correct about creating a function with a prototype. @NoQ -- do you agree with that fix?

[tahonermann]

clang/lib/StaticAnalyzer/Core/MemRegion.cpp

1034–1042

I haven't studied the surrounding code much, so perhaps this comment isn't applicable, but I would expect FunctionProtoType to be applicable when an empty parameter list is explicitly specified as in ^ () { ... } prior to C2x.

[aaron.ballman]

clang/include/clang/Basic/LangOptions.def

124

This makes me think we should have some declarative way of specifying dependencies between LANGOPTs.

Tee hee: https://github.com/llvm/llvm-project/commit/be9371659380388a693ec99624e1f3d02f07047f

I was caught by the same issues that I ended up fixing in that commit -- I tried making StrictPrototypes dependent and was very surprised when it doesn't work. The issue was Invocation->getLangOpts()->resetNonModularOptions(); in compileModuleImpl() IIRC -- it would clear all of the language options (including ones like digraphs and wchar support).

There's actually a secondary issue, which is that users can set language options directly -- there's not a setter function for them. This means that places where we create a LangOptions object and manually set it up (like our unit tests) have no way to automatically set StrictPrototypes when setting other language options.

However, this speaks to the importance of having an assert to ensure that by the time the compiler instance is invoked, we have language options that are correct (on the assumption that later stages will not be modifying the language options particularly often).

[aaron.ballman]

Updated based on review feedback.

• Added -fstrict-prototypes command line option (but there is NO -fno-strict-prototypes support)
• Changed the way the language option works to be a little less fragile
• Fixed the static analyzer to create a function with a prototype instead

[aaron.ballman]

clang/include/clang/Basic/LangOptions.def

124

I ended up reworking this so that the language option is only for the command line extension, and there's a helper method to ask whether strict prototypes is enabled (based on the values of the language options). It's still a little fragile (someone could use the language option instead of the helper method), but I think that's mitigated by the name of the language option.

clang/lib/Parse/ParseDecl.cpp

6664–6666

I updated both comments.

clang/lib/StaticAnalyzer/Core/MemRegion.cpp

1034–1042

I changed to create a function with a prototype instead; no tests broke when I did that as well.

[rsmith]

LGTM. Some comments for potential improvements, but I'd be OK with this landing as-is if you don't find any of them sufficiently motivating :)

clang/lib/Parse/ParseDecl.cpp

6664–6666

Fascinating! There's a common confusion and misapprehension that void f() declares a variadic function in C, and that confusion has made its way into the OpenCL specification. The relevant rule there is 6.11/g:

e. Variadic functions are not supported, with the exception of printf and enqueue_kernel.
g. If a list of parameters in a function declaration is empty, the function takes no arguments. This is due to the above restriction on variadic functions.

(Emphasis mine.) So I think this implementation is correct, and your earlier comment correctly reflected the confusion in the OpenCL spec :-)

A comment with a direct reference to this part of the OpenCL C 3.0 specification would be nice.

6667

Hm, so -fstrict-prototypes causes us to treat void f() as void f(void)? That's not normally how our -fstrict- flags work: normally they mean "strictly enforce this language rule, even though that may result in programs having UB that we could define away with a more permissive rule". (For example, -fstrict-aliasing, -fstrict-float-cast-overflow, -fstrict-enums, -fstrict-overflow, -fstrict-vtable-pointers, -fstrict-return all work like that.) I wonder if a different flag name would work better, eg -fno-unprototyped-functions. Is -fstrict-prototypes a GCC flag that we're trying to be compatible with, or our own invention?

If you can't find a better name, I'm not dead set against the current one, but it does seem a little inconsistent.

clang/test/Driver/strict-prototypes.c

5 ↗

(On Diff #423629)

I would expect this case (-std=c89 -fno-strict-prototypes) to work: we usually allow -fno-X flag to override an earlier -fX flag in the same command line. Not a big deal, though.

[aaron.ballman]

clang/lib/Parse/ParseDecl.cpp

6664–6666

Fascinating! There's a common confusion and misapprehension that void f() declares a variadic function in C, and that confusion has made its way into the OpenCL specification.

I think it's understandable confusion. void f(...); in C++ and void f(); in C89 say the "same" thing: this function can be called with zero or more arguments, YOLO. The fact that the standards made ... mean "variadic" but functions without a prototype mean "magic" is mostly lost on users, I think.

A comment with a direct reference to this part of the OpenCL C 3.0 specification would be nice.

I'll add that link in, good call!

6667

Hm, so -fstrict-prototypes causes us to treat void f() as void f(void)?

Yup, the idea is that it is strictly enforcing that all functions have a prototype.

Is -fstrict-prototypes a GCC flag that we're trying to be compatible with, or our own invention?

It's our invention, and I'm not strongly tied to the name. It's the one that came up during the RFC and I suspect it's influenced by the name of the warning group -Wstrict-prototypes.

I think -fno- would be a bit of a weird way to spell the flag as that usually disables something rather than enables it. I'll switch to -fforce-prototypes because that's basically what this does. WDYT?

clang/test/Driver/strict-prototypes.c

5 ↗

(On Diff #423629)

I think it's better to disallow the user from ever uttering -fno-strict-prototypes even when it's behavior would be benign. But I'm happy to revisit later if it becomes an issue.

[aaron.ballman]

clang/lib/Parse/ParseDecl.cpp

6667

After a bunch of off-list discussion with @tahonermann and @erichkeane, we landed on -fno-knr-functions as the proposed new name for the flag.

clang/docs/ReleaseNotes.rst

 -------------------
 
 - Implemented `WG14 N2674 The noreturn attribute <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf>`_.
 - Implemented `WG14 N2935 Make false and true first-class language features <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2935.pdf>`_.
 - Implemented `WG14 N2763 Adding a fundamental type for N-bit integers <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf>`_.
 - Implemented `WG14 N2775 Literal suffixes for bit-precise integers <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2775.pdf>`_.
 - Implemented the `*_WIDTH` macros to complete support for
   `WG14 N2412 Two's complement sign representation for C2x <https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf>`_.
+- Implemented `WG14 N2841 No function declarators without prototypes <https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm>`_
+  and `WG14 N2432 Remove support for function definitions with identifier lists <https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf>`_.
 
 C++ Language Changes in Clang
 -----------------------------
 
 - Improved ``-O0`` code generation for calls to ``std::move``, ``std::forward``,
   ``std::move_if_noexcept``, ``std::addressof``, and ``std::as_const``. These
   are now treated as compiler builtins and implemented directly, rather than
   instantiating the definition from the standard library.

clang/include/clang/Basic/LangOptions.def

 LANGOPT(IEEE128           , 1, 0, "__ieee128 keyword")
 LANGOPT(DeclSpecKeyword   , 1, 0, "__declspec keyword")
 BENIGN_LANGOPT(DollarIdents   , 1, 1, "'$' in identifiers")
 BENIGN_LANGOPT(AsmPreprocessor, 1, 0, "preprocessor in asm mode")
 LANGOPT(GNUMode           , 1, 1, "GNU extensions")
 LANGOPT(GNUKeywords       , 1, 1, "GNU keywords")
 VALUE_LANGOPT(GNUCVersion , 32, 0, "GNU C compatibility version")
 BENIGN_LANGOPT(ImplicitInt, 1, 0, "C89 implicit 'int'")
+LANGOPT(StrictPrototypes  , 1, 0, "require function types to have a prototype")
 LANGOPT(Digraphs          , 1, 0, "digraphs")
 BENIGN_LANGOPT(HexFloats  , 1, 0, "C99 hexadecimal float constants")
 LANGOPT(CXXOperatorNames  , 1, 0, "C++ operator name keywords")
 LANGOPT(AppleKext         , 1, 0, "Apple kext support")
 BENIGN_LANGOPT(PascalStrings, 1, 0, "Pascal string support")
 LANGOPT(WritableStrings   , 1, 0, "writable string support")
 LANGOPT(ConstStrings      , 1, 0, "const-qualified string support")
 ENUM_LANGOPT(LaxVectorConversions, LaxVectorConversionKind, 2,

clang/lib/AST/ASTContext.cpp

          (T.getObjCLifetime() == Qualifiers::OCL_None ||
           T.getObjCLifetime() == Qualifiers::OCL_ExplicitNone);
 }
 
 /// getFunctionNoProtoType - Return a K&R style C function type like 'int()'.
 QualType
 ASTContext::getFunctionNoProtoType(QualType ResultTy,
                                    const FunctionType::ExtInfo &Info) const {
+  // FIXME: This assertion cannot be enabled (yet) because the ObjC rewriter
+  // functionality creates a function without a prototype regardless of
+  // language mode (so it makes them even in C++). Once the rewriter has been
+  // fixed, this assertion can be enabled again.
+  //assert(!LangOpts.StrictPrototypes && "strict prototypes are disabled");
+
   // Unique functions, to guarantee there is only one function of a particular
   // structure.
   llvm::FoldingSetNodeID ID;
   FunctionNoProtoType::Profile(ID, ResultTy, Info);
 
   void *InsertPos = nullptr;
   if (FunctionNoProtoType *FT =
         FunctionNoProtoTypes.FindNodeOrInsertPos(ID, InsertPos))

 
   bool Variadic = (TypeStr[0] == '.');
 
   FunctionType::ExtInfo EI(getDefaultCallingConvention(
       Variadic, /*IsCXXMethod=*/false, /*IsBuiltin=*/true));
   if (BuiltinInfo.isNoReturn(Id)) EI = EI.withNoReturn(true);
 
 
   // We really shouldn't be making a no-proto type here.
-  if (ArgTypes.empty() && Variadic && !getLangOpts().CPlusPlus)
+  if (ArgTypes.empty() && Variadic && !getLangOpts().StrictPrototypes)
     return getFunctionNoProtoType(ResType, EI);
 
   FunctionProtoType::ExtProtoInfo EPI;
   EPI.ExtInfo = EI;
   EPI.Variadic = Variadic;
   if (getLangOpts().CPlusPlus && BuiltinInfo.isNoThrow(Id))
     EPI.ExceptionSpec.Type =
         getLangOpts().CPlusPlus11 ? EST_BasicNoexcept : EST_DynamicNone;

clang/lib/Basic/LangOptions.cpp

void LangOptions::setLangDefaults(LangOptions &Opts, Language Lang,
   Opts.CPlusPlus20 = Std.isCPlusPlus20();
   Opts.CPlusPlus2b = Std.isCPlusPlus2b();
   Opts.GNUMode = Std.isGNUMode();
   Opts.GNUCVersion = 0;
   Opts.HexFloats = Std.hasHexFloats();
   Opts.ImplicitInt = Std.hasImplicitInt();
   Opts.WChar = Std.isCPlusPlus();
   Opts.Digraphs = Std.hasDigraphs();
+  Opts.StrictPrototypes = Std.isCPlusPlus() || Std.isC2x();
 
   Opts.HLSL = Lang == Language::HLSL;
 
   // Set OpenCL Version.
   Opts.OpenCL = Std.isOpenCL();
   if (LangStd == LangStandard::lang_opencl10)
     Opts.OpenCLVersion = 100;
   else if (LangStd == LangStandard::lang_opencl11)

clang/lib/Parse/ParseDecl.cpp

     ProhibitAttributes(FnAttrs);
   } else {
     if (Tok.isNot(tok::r_paren))
       ParseParameterDeclarationClause(D.getContext(), FirstArgAttrs, ParamInfo,
                                       EllipsisLoc);
     else if (RequiresArg)
       Diag(Tok, diag::err_argument_required_after_attribute);
 
-    HasProto = ParamInfo.size() || getLangOpts().CPlusPlus
-                                || getLangOpts().OpenCL;
+    // OpenCL disallows variadic functions, so it also disallows a function
+    // without a prototype. However, it doesn't enforce strict prototypes
+    // because it allows function definitions with an identifier list.
+    HasProto = ParamInfo.size() || getLangOpts().StrictPrototypes ||
+               getLangOpts().OpenCL;
 
     // If we have the closing ')', eat it.
     Tracker.consumeClose();
     RParenLoc = Tracker.getCloseLocation();
     LocalEndLoc = RParenLoc;
     EndLoc = RParenLoc;
 
     if (getLangOpts().CPlusPlus) {

 }
 
 /// isFunctionDeclaratorIdentifierList - This parameter list may have an
 /// identifier list form for a K&R-style function:  void foo(a,b,c)
 ///
 /// Note that identifier-lists are only allowed for normal declarators, not for
 /// abstract-declarators.
 bool Parser::isFunctionDeclaratorIdentifierList() {
-  return !getLangOpts().CPlusPlus
+  return !getLangOpts().StrictPrototypes
          && Tok.is(tok::identifier)
          && !TryAltiVecVectorToken()
          // K&R identifier lists can't have typedefs as identifiers, per C99
          // 6.7.5.3p11.
          && (TryAnnotateTypeOrScopeToken() || !Tok.is(tok::annot_typename))
          // Identifier lists follow a really simple grammar: the identifiers can
          // be followed *only* by a ", identifier" or ")".  However, K&R
          // identifier lists are really rare in the brave new modern world, and

 ///
 ///       identifier-list: [C99 6.7.5]
 ///         identifier
 ///         identifier-list ',' identifier
 ///
 void Parser::ParseFunctionDeclaratorIdentifierList(
        Declarator &D,
        SmallVectorImpl<DeclaratorChunk::ParamInfo> &ParamInfo) {
+  // We should never reach this point in C2x or C++.
+  assert(!getLangOpts().StrictPrototypes &&
+         "Cannot parse an identifier list in C2x or C++");
+
   // If there was no identifier specified for the declarator, either we are in
   // an abstract-declarator, or we are in a parameter declarator which was found
   // to be abstract.  In abstract-declarators, identifier lists are not valid:
   // diagnose this.
   if (!D.getIdentifier())
     Diag(Tok, diag::ext_ident_list_in_param);
 
   // Maintain an efficient lookup of params we have seen so far.

clang/lib/Sema/SemaDecl.cpp

     //     declarator to still have a function type. e.g.,
     //       typedef void func(int a);
     //       __attribute__((noreturn)) func other_func; // This has a prototype
     bool HasPrototype =
         (D.isFunctionDeclarator() && D.getFunctionTypeInfo().hasPrototype) ||
         (D.getDeclSpec().isTypeRep() &&
          D.getDeclSpec().getRepAsType().get()->isFunctionProtoType()) ||
         (!R->getAsAdjusted<FunctionType>() && R->isFunctionProtoType());
+    assert((HasPrototype || !SemaRef.getLangOpts().StrictPrototypes) &&
+           "Strict prototypes are required");
 
     NewFD = FunctionDecl::Create(
         SemaRef.Context, DC, D.getBeginLoc(), NameInfo, R, TInfo, SC,
         SemaRef.getCurFPFeatures().isFPConstrained(), isInline, HasPrototype,
         ConstexprSpecKind::Unspecified,
         /*TrailingRequiresClause=*/nullptr);
     if (D.isInvalidType())
       NewFD->setInvalidDecl();
 

clang/lib/Sema/SemaType.cpp

       // If we see "T var();" or "T var(T());" at block scope, it is probably
       // an attempt to initialize a variable, not a function declaration.
       if (FTI.isAmbiguous)
         warnAboutAmbiguousFunction(S, D, DeclType, T);
 
       FunctionType::ExtInfo EI(
           getCCForDeclaratorChunk(S, D, DeclType.getAttrs(), FTI, chunkIndex));
 
-      if (!FTI.NumParams && !FTI.isVariadic && !LangOpts.CPlusPlus
-                                            && !LangOpts.OpenCL) {
+      // OpenCL disallows variadic functions, so it also disallows a function
+      // without a prototype. However, it doesn't enforce strict prototypes
+      // because it allows function definitions with an identifier list.
+      if (!FTI.NumParams && !FTI.isVariadic && !LangOpts.StrictPrototypes &&
+          !LangOpts.OpenCL) {
         // Simple void foo(), where the incoming T is the result type.
         T = Context.getFunctionNoProtoType(T, EI);
       } else {
         // We allow a zero-parameter variadic function in C if the
         // function is marked with the "overloadable" attribute. Scan
         // for this attribute now.
         if (!FTI.NumParams && FTI.isVariadic && !LangOpts.CPlusPlus)
           if (!D.getAttributes().hasAttribute(ParsedAttr::AT_Overloadable) &&
               !D.getDeclSpec().getAttributes().hasAttribute(
                   ParsedAttr::AT_Overloadable))
             S.Diag(FTI.getEllipsisLoc(), diag::err_ellipsis_first_param);
 
         if (FTI.NumParams && FTI.Params[0].Param == nullptr) {
           // C99 6.7.5.3p3: Reject int(x,y,z) when it's not a function
           // definition.
           S.Diag(FTI.Params[0].IdentLoc,
                  diag::err_ident_list_in_fn_declaration);
           D.setInvalidType(true);
-          // Recover by creating a K&R-style function type.
-          T = Context.getFunctionNoProtoType(T, EI);
+          // Recover by creating a K&R-style function type, if possible.
+          T = (!LangOpts.StrictPrototypes && !LangOpts.OpenCL)
+                  ? Context.getFunctionNoProtoType(T, EI)
+                                         : Context.IntTy;
           break;
         }
 
         FunctionProtoType::ExtProtoInfo EPI;
         EPI.ExtInfo = EI;
         EPI.Variadic = FTI.isVariadic;
         EPI.EllipsisLoc = FTI.getEllipsisLoc();
         EPI.HasTrailingReturn = FTI.hasTrailingReturnType();

clang/lib/StaticAnalyzer/Core/MemRegion.cpp

         else if (const auto *BD = dyn_cast<BlockDecl>(STCD)) {
           // FIXME: The fallback type here is totally bogus -- though it should
           // never be queried, it will prevent uniquing with the real
           // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
           // signature.
           QualType T;
           if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
             T = TSI->getType();
-          if (T.isNull())
-            T = getContext().VoidTy;
-          if (!T->getAs<FunctionType>())
-            T = getContext().getFunctionNoProtoType(T);
-          T = getContext().getBlockPointerType(T);
-
-          const BlockCodeRegion *BTR =
-            getBlockCodeRegion(BD, Ctx.getCanonicalType(T),
-                               STC->getAnalysisDeclContext());
-          sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
-                                  BTR);
+          if (T.isNull() || !T->getAs<FunctionType>())
+            // If the type is invalid or is not a function type, we cannot get
+            // a block pointer type for it. This isn't ideal, but it's better
+            // than asserting in getBlockPointerType() or creating a function
+            // without a prototype in a language that has no such concept (like
+            // C++ or C2x).
+            sReg = getUnknownRegion();
+          else {
+            T = getContext().getBlockPointerType(T);
+
+            const BlockCodeRegion *BTR = getBlockCodeRegion(
+                BD, Ctx.getCanonicalType(T), STC->getAnalysisDeclContext());
+            sReg =
+                getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind, BTR);
+          }
         }
         else {
           sReg = getGlobalsRegion();
         }
       }
     }
   }
 

clang/test/Parser/c2x-attributes.c

-// RUN: %clang_cc1 -fsyntax-only -fdouble-square-bracket-attributes -verify -Wno-strict-prototypes %s
-// RUN: %clang_cc1 -fsyntax-only -std=gnu2x -verify -Wno-strict-prototypes %s
+// RUN: %clang_cc1 -fsyntax-only -fdouble-square-bracket-attributes -verify=expected,notc2x -Wno-strict-prototypes %s
+// RUN: %clang_cc1 -fsyntax-only -std=gnu2x -verify=expected,c2x %s
 
 enum [[]] E {
   One [[]],
   Two,
   Three [[]]
 };
 
 enum [[]] { Four };

 
 [[]] void f1(void);
 void [[]] f2(void);
 void f3 [[]] (void);
 void f4(void) [[]];
 
 void f5(int i [[]], [[]] int j, int [[]] k);
 
-void f6(a, b) [[]] int a; int b; { // expected-error {{an attribute list cannot appear here}}
+void f6(a, b) [[]] int a; int b; { // notc2x-error {{an attribute list cannot appear here}} \
+                                      c2x-warning 2 {{type specifier missing, defaults to 'int'}} \
+                                      c2x-error {{expected ';' after top level declarator}} \
+                                      c2x-error {{expected identifier or '('}}
 }
 
 // FIXME: technically, an attribute list cannot appear here, but we currently
 // parse it as part of the return type of the function, which is reasonable
 // behavior given that we *don't* want to parse it as part of the K&R parameter
 // declarations. It is disallowed to avoid a parsing ambiguity we already
 // handle well.
-int (*f7(a, b))(int, int) [[]] int a; int b; {
+int (*f7(a, b))(int, int) [[]] int a; int b; { // c2x-warning 2 {{type specifier missing, defaults to 'int'}} \
+                                                  c2x-error {{expected ';' after top level declarator}} \
+                                                  c2x-error {{expected identifier or '('}}
+
   return 0;
 }
 
 [[]] int a, b;
 int c [[]], d [[]];
 
 void f8(void) [[]] {
   [[]] int i, j;

clang/test/Parser/c2x-func-prototype.c

+// RUN: %clang_cc1 -fsyntax-only -verify=c2x -std=c2x %s
+// RUN: %clang_cc1 -Wno-strict-prototypes -fsyntax-only -verify -std=c17 %s
+// expected-no-diagnostics
+
+// Functions with an identifier list are not supported in C2x.
+void ident_list(a) // c2x-error {{expected ';' after top level declarator}} \
+                      c2x-warning {{type specifier missing, defaults to 'int'}}
+  int a;
+{}                 // c2x-error {{expected identifier or '('}}
+
+// Functions with an empty parameter list are supported as though the function
+// was declared with a parameter list of (void). Ensure they still parse.
+void no_param_decl();
+void no_param_defn() {}
+void (*var_of_type_with_no_param)();
+typedef void fn();

clang/test/Sema/attr-c2x.c

 [[clang::overloadable]] void foo(char *c);
 
 void context_okay(void *context [[clang::swift_context]]) [[clang::swiftcall]];
 void context_okay2(void *context [[clang::swift_context]], void *selfType, char **selfWitnessTable) [[clang::swiftcall]];
 void context_async_okay(void *context [[clang::swift_async_context]]) [[clang::swiftasynccall]];
 void context_async_okay2(void *context [[clang::swift_async_context]], void *selfType, char **selfWitnessTable) [[clang::swiftasynccall]];
 
 [[clang::ownership_returns(foo)]] void *f1(void);
-[[clang::ownership_returns(foo)]] void *f2(); // expected-warning {{'ownership_returns' attribute only applies to non-K&R-style functions}}
+[[clang::ownership_returns(foo)]] void *f2();
 
 [[clang::unavailable("not available - replaced")]] void foo2(void); // expected-note {{'foo2' has been explicitly marked unavailable here}}
 void bar(void) {
   foo2(); // expected-error {{'foo2' is unavailable: not available - replaced}}
 }
 
 [[nodiscard]] int without_underscores(void);
 [[__nodiscard__]] int underscores(void);

clang/test/Sema/c2x-func-prototype.c

+// RUN: %clang_cc1 -fsyntax-only -verify=c2x -std=c2x %s
+// RUN: %clang_cc1 -Wno-strict-prototypes -fsyntax-only -verify -std=c17 %s
+// expected-no-diagnostics
+
+void func(); // c2x-note {{'func' declared here}}
+typedef void (*fp)();
+
+void other_func(int i);
+
+void call(void) {
+  func(1, 2, 3); // c2x-error {{too many arguments to function call, expected 0, have 3}}
+  fp call_me = func;
+  call_me(1, 2, 3); // c2x-error {{too many arguments to function call, expected 0, have 3}}
+
+  fp nope = other_func; // c2x-warning {{incompatible function pointer types initializing 'fp' (aka 'void (*)(void)') with an expression of type 'void (int)'}}
+}
+
+// Ensure these function declarations do not merge in C2x.
+void redecl1();      // c2x-note {{previous declaration is here}}
+void redecl1(int i); // c2x-error {{conflicting types for 'redecl1'}}
+
+void redecl2(int i); // c2x-note {{previous declaration is here}}
+void redecl2();      // c2x-error {{conflicting types for 'redecl2'}}

clang/tools/clang-import-test/clang-import-test.cpp

std::unique_ptr<CompilerInstance> BuildCompilerInstance() {
   {
     using namespace driver::types;
     ID Id = lookupTypeForTypeSpecifier(Input.c_str());
     assert(Id != TY_INVALID);
     if (isCXX(Id)) {
       Inv->getLangOpts()->CPlusPlus = true;
       Inv->getLangOpts()->CPlusPlus11 = true;
       Inv->getHeaderSearchOpts().UseLibcxx = true;
+      Inv->getLangOpts()->StrictPrototypes = true;
     }
     if (isObjC(Id)) {
       Inv->getLangOpts()->ObjC = 1;
     }
   }
   Inv->getLangOpts()->ObjCAutoRefCount = ObjCARC;
 
   Inv->getLangOpts()->Bool = true;

clang/www/c_status.html

</tr>
     <tr>
       <td>Adding the u8 character prefix</td>
       <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2418.pdf">N2418</a></td>
       <td class="none" align="center">No</td>
     </tr>
     <tr>
       <td>Remove support for function definitions with identifier lists</td>
       <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf">N2432</a></td>
-      <td class="none" align="center">No</td>
+      <td class="unreleased" align="center">Clang 15</td>
     </tr>
     <!-- Oct 2019 Papers -->
     <tr>
       <td>*_IS_IEC_60559 feature test macros</td>
       <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2379.htm">N2379</a></td>
       <td class="unknown" align="center">Unknown</td>
     </tr>
     <tr>