Commit Graph

8 Commits

Author SHA1 Message Date
Eli Friedman 2b680b43e9 Simplify the scheme used for keywords, and change the classification
scheme to be more useful.

The new scheme introduces a set of categories that should be more 
readable, and also reflects what we want to consider as an extension 
more accurately.  Specifically, it makes the "what is a keyword" 
determination accurately reflect whether the keyword is a GNU or 
Microsoft extension.

I also introduced separate flags for keyword aliases; this is useful 
because the classification of the aliases is mostly unrelated to the 
classification of the original keyword.

This patch treats anything that's in the implementation 
namespace (prefixed with "__", or "_X" where "X" is any upper-case 
letter) as a keyword without marking it as an extension.  This is 
consistent with the standards in that an implementation is allowed to define 
arbitrary extensions in the implementation namespace without violating 
the standard. This gets rid of all the nasty "extension used" warnings 
for stuff like __attribute__ in -pedantic mode.  We still warn for 
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we 
could add additional information to the keyword table.

This also removes processing for the unused "Boolean" language option; 
such an extension isn't supported on any other C implementation, so I 
don't see any point to adding it.

The changes to test/CodeGen/inline.c are required because previously, we 
weren't actually disabling the "inline" keyword in -std=c89 mode.

I'll remove Boolean and NoExtensions from LangOptions in a follow-up 
commit.

llvm-svn: 70281
2009-04-28 03:13:54 +00:00
Douglas Gregor 89c8e000cf Fix handling of C99 "extern inline" semantics when dealing with
multiple declarations of the function. Should fix PR3989 and
<rdar://problem/6818429>.

llvm-svn: 69905
2009-04-23 18:22:55 +00:00
Chris Lattner f8dc07369a Fix some mishandling of the attr(gnu_inline) mode when used with
extern.  Previously we would warn about it and ignore the attribute.
This is incorrect, it should be handled as a c89 "extern inline" 
function.  Many thanks to Matthieu Castet for pointing this out and
beating me over the head until I got it.

PR3988: extern inline function are not externally visible
llvm-svn: 69756
2009-04-22 00:03:30 +00:00
Chris Lattner ddf6ca0355 the __gnuc_inline__ attribute is actually named __gnu_inline__,
PR4023

llvm-svn: 69618
2009-04-20 19:12:28 +00:00
Chris Lattner bae0e68930 Fix PR3988: extern inline functions get strong symbol definitions in
C99 mode.  This is a regression from an earlier patch of mine.

This also simplifies the linkage enums a bit.

llvm-svn: 69069
2009-04-14 20:25:53 +00:00
Chris Lattner 02e987f3e8 implement codegen support for __attribute((__gnuc_inline__)),
pulling some attribute munging stuff into GetLinkageForFunction.

This should fix PR3986

llvm-svn: 69045
2009-04-14 16:44:36 +00:00
Chris Lattner 92028dad66 defer emission of always_inline, extern_inline, and inline functions (when
not in c89 mode).

llvm-svn: 69032
2009-04-14 06:44:48 +00:00
Chris Lattner 256c9507c8 set the linkage of an inline function according to its language rules.
llvm-svn: 69030
2009-04-14 06:27:57 +00:00