Commit Graph

7 Commits

Author SHA1 Message Date
Aaron Ballman 7d644e1215 [C11/C2x] Change the behavior of the implicit function declaration warning
C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.

C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.

C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.

This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.

Differential Revision: https://reviews.llvm.org/D122983
2022-04-20 11:30:12 -04:00
Aaron Ballman e9e55acd1b Use functions with prototypes when appropriate; NFC
A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

  void func();

becomes

  void func(void);

This is the seventh batch of tests being updated (there are a
significant number of other tests left to be updated).
2022-02-10 16:06:03 -05:00
Douglas Gregor cb28f9d7ad Rework the (de-)serialization of macros, as stored in
MacroInfo*. Instead of simply dumping an offset into the current file,
give each macro definition a proper ID with all of the standard
modules-remapping facilities. Additionally, when a macro is modified
in a subsequent AST file (e.g., #undef'ing a macro loaded from another
module or from a precompiled header), provide a macro update record
rather than rewriting the entire macro definition. This gives us
greater consistency with the way we handle declarations, and ties
together macro definitions much more cleanly.

Note that we're still not actually deserializing macro history (we
never were), but it's far easy to do properly now.

llvm-svn: 165560
2012-10-09 23:05:51 +00:00
Douglas Gregor 2ed0ee1ace Eliminate the -chained-pch flag and all of the frontend and libclang options associated with it. Chained PCH is the only way to build a PCH file that includes another PCH file
llvm-svn: 138597
2011-08-25 22:54:01 +00:00
Douglas Gregor 9109629e55 Implement chained PCH support for the macro definitions stored within
the "detailed" preprocessing record.

llvm-svn: 115417
2010-10-02 19:29:26 +00:00
Douglas Gregor eb114da506 When an identifier that has a macro definition in the original PCH
file is somehow changed in a chained PCH file, make sure that we write
out the macro definition. Fixes part of <rdar://problem/8499034>.

llvm-svn: 115259
2010-10-01 01:03:07 +00:00
Sebastian Redl 07a89a83d4 Make macro weirdness in chained PCH work. This required changing the way PCHReader and PCHWriter are initialized to correctly pick up all initializer. On the upside, this means that there is far less repetition in the dependent PCH now.
llvm-svn: 109823
2010-07-30 00:29:29 +00:00