replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/clang/test/Parser/attributes.c

55 lines
1.7 KiB
C
Raw Normal View History

Rename clang to clang-cc. Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
2009-03-24 10:24:46 +08:00
// RUN: clang-cc -fsyntax-only -verify %s -pedantic -std=c99
new testcase llvm-svn: 39000
2006-10-17 11:00:45 +08:00
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 11:13:54 +08:00
int __attribute__(()) x;
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
__inline void __attribute__((__always_inline__, __nodebug__))
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
foo(void) {
new testcase llvm-svn: 39000
2006-10-17 11:00:45 +08:00
}
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
__attribute__(()) y; // expected-warning {{defaults to 'int'}}
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
// PR2796
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 11:13:54 +08:00
int (__attribute__(()) *z)(long y);
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
void f1(__attribute__(()) int x);
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
int f2(y, __attribute__(()) x); // expected-error {{expected identifier}}
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
// This is parsed as a normal argument list (with two args that are implicit
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 11:13:54 +08:00
// int) because the __attribute__ is a declspec.
void f3(__attribute__(()) x, // expected-warning {{defaults to 'int'}}
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
y); // expected-warning {{defaults to 'int'}}
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 11:13:54 +08:00
void f4(__attribute__(())); // expected-error {{expected parameter declarator}}
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
// This is ok, the __attribute__ applies to the pointer.
int baz(int (__attribute__(()) *x)(long y));
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
void g1(void (*f1)(__attribute__(()) int x));
void g2(int (*f2)(y, __attribute__(()) x)); // expected-error {{expected identifier}}
void g3(void (*f3)(__attribute__(()) x, int y)); // expected-warning {{defaults to 'int'}}
void g4(void (*f4)(__attribute__(()))); // expected-error {{expected parameter declarator}}
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
void (*h1)(void (*f1)(__attribute__(()) int x));
void (*h2)(int (*f2)(y, __attribute__(()) x)); // expected-error {{expected identifier}}
Fix a parser bug where we let attributes interfere with our disambiguation of whether a '(' was a grouping paren or the start of a function declarator. This is PR2796. Now we eat the attribute before deciding whether the paren is grouping or not, then apply it to the resultant decl or to the first argument as needed. One somewhat surprising aspect of this is that attributes interact with implicit int in cases like this: void a(x, y) // k&r style function void b(__attribute__(()) x, y); // function with two implicit int arguments void c(x, __attribute__(()) y); // error, can't have attr in identifier list. Fun stuff. llvm-svn: 57790
2008-10-20 10:05:46 +08:00
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 11:13:54 +08:00
void (*h3)(void (*f3)(__attribute__(()) x)); // expected-warning {{defaults to 'int'}}
void (*h4)(void (*f4)(__attribute__(()))); // expected-error {{expected parameter declarator}}
Support attributes in *yet another* place. Is there any place you can't stick an attributes? llvm-svn: 57795
2008-10-20 12:57:38 +08:00
// rdar://6131260
int foo42(void) {
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 11:13:54 +08:00
int x, __attribute__((unused)) y, z;
Support attributes in *yet another* place. Is there any place you can't stick an attributes? llvm-svn: 57795
2008-10-20 12:57:38 +08:00
return 0;
}
// rdar://6096491
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 11:13:54 +08:00
void __attribute__((noreturn)) d0(void), __attribute__((noreturn)) d1(void);
Support attributes in *yet another* place. Is there any place you can't stick an attributes? llvm-svn: 57795
2008-10-20 12:57:38 +08:00
Fix attribute between function decl ')' and '{' or '=0' llvm-svn: 89894
2009-11-26 06:58:06 +08:00
void d2(void) __attribute__((noreturn)), d3(void) __attribute__((noreturn));